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Theme 


A  tai^  amennt  of  researdi  is*  being  Cbifducted  to  develop' and  apply  Machine  Intelligence  (MI)  technology  to  aerospace 
applications.  Machine  Intelligence  research  covers  the  technical  areas  under  the  headings  of  Artificial  Intelligetice,  Expert 
Systems,  Knowledge  Representation,  Neural  Networks  and  Machine  Learning.  This  list  is  not  all  inclusive.  It  has  been 
suggested  that  this  research  will  dramatically  alter  the  design  of  aerospace  electronics  systems  because  MI  technology  enables 
automatic  or  semi-automatic  operation  and  control.  Some  of  the  application  areas  where  MI  is  being  considered  include  sensor 
cueing,  data  and  information  &sion,  command/control/communications/intelligence,  navigation  and  guidance,  pilot  aiding, 
spacecraft  and  launch  operations,  and  logistics  support  for  aerospace  electronics.  For  many  routine  jobs,  it  appears  that  MI 
systems  could  totally  displace  human  operators.  In  other  situations,  MI  systems  would  provide  screened  and  processed  data  as 
well  as  recommended  courses  of  action  to  human  operators.  MI  technology  will  enable  electronic  systems  or  subsystems  which 
adapt  or  correct  for  errors  and  many  of  the  paradigms  have  parallel  implementation  or  use  intelligent  algorithms  to  increase  the 
speed  of  response  to  near  real  time^ 

-  j  ms  symposium  presents  the  results  of  efforts  applying  MI  technology  to  aerospace  electronics  applications.  The  symposium 
focuses  on  applications  research  and  development  to  determine  the  types  of  MI  paradigms  which  are  best  suited  to  the  wide 
variety  of  aerospace  electronics  applications. 


Theme 


Des  efforts  importants  sont  actuellement  consacres  au  developpement  et  a  I'application  des  technologies  de  I'intelligence 
artihcielle  (lA)  dans  le  domaine  aerospatial.  La  recherche  en  intelligence  artificielle  couvre:  I'intelligence  artificielle,  les 
systemes  experts,  la  representation  des  connaissances,  les  reseaux  neuronaux  et  I'apprentissage  automatique. 

La  liste  n’est  point  exhaustive.  Pour  certains,  les  resultats  de  ces  recherches  auront  pour  effet  la  transformation  radicale  de  la 
conception  des  systemes  electroniques  aerospatiaux  puisque  les  technologies  de  I'lA  permeltent  la  commande  et  la  controle 
automatiques  et  semi-automatiques.  Parmi  les  domaines  d'application  oil  I'lA  est  a  I’etude  on  distingue;  I'alignement  des 
capteurs,  le  fusionnement  des  donn^  et  des  informations,  le  commandement,  le  controle,  les  communications  et  le 
renseignement,  la  navigation  et  le  guidage,  I'aide  au  pilote,  les  operations  des  vehicules  spatiaux  et  les  techniques  de  lancement, 
ainsi  que  le  soutien  logistique  de  I’electronique  aerospatiale. 

Ainsi,  des  systemes  lA  remplaceront  totalement  I’operateur  humain  pour  de  nombreuses  taches  de  routine.  Dans  d’autres 
situations  encore,  les  systemes  LA  foumiront  a  I’operateur  humain  des  donnees  selectionn^  et  traitees  ainsi  que  des 
recommendations  concemant  les  actions  a  prendre.  Les  technologies  de  I’lA  permettront  de  reiser  des  systemes  et  des  sous- 
systemes  electroniques  qui  s'adaptent  aux  erreurs  ou  qui  les  corrigent.  Bon  nombre  des  paradigmes  peuvent  etre  mis  en  oeuvre 
en  parallde  et  font  appel  a  des  algorithmes  intelligents  qui  permettent  d’atteindre  des  temps  de  reponse  en  quasi-tempts  r^l. 

Ce  symposium  a  presente  les  efforts  qui  ont  ete  consaern  a  I'application  des  technologies  de  I'lA  aux  problemes  de 
I'electronique  aerospatiale.  Ce  symposium  a  porte  sur  les  travaux  de  recherche  et  de  developpement  en  cours,  du  point  de  vue 
des  applications,  afin  d'identifier  les  paradigmes  lA  les  mieux  adapts  a  I'eventail  d'applications  qui  se  presente  dans  le 
domaine  de  I'electronique  aerospatiale. 
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The  overall  qualitv  of  the  papers  and 
presentations  at  this  syaqposium  vas 
excellent.  The  location,  facilities, 
interpreters,  and  arrangeoients  were 
outstanding.  The  call  for  papers  produced  a 
moderate  number  of  submissions,  and  the 
papers  that  were  accepted  and  presoited 
possessed  a  cross  section  of  activities 
tacmted  at  aerospace  applications.  The 
Machine  Intelligence  technologies  included 
within  the  31  applications  papers  were 
primarily  Expert  ^sterns.  Knowledge  Based 
^sterns,  and  five  Neural  Network  papers. 

The  applications  presented  covered  a  variety 
of  aerospace  areas,  including  mission 
planning,  navigation,  communicatiais, 
electronic  warfare,  resource  management, 
diafffiostics,  target  recognition,  and  pilot 
aiding.  All  countries  had  broad  interests 
in  the  Machine  Intelligence  technologies  and 
the  application  areas  presented. 

Obviously,  a  four-day  conference  cannot 
review  all  the  MI  work  being  accoiqplished 
throughout  all  the  member  nations.  The 
emphasis  of  the  symposium  was  on  MI 
applications  for  Aerospace  Electronics 
^tens;  however,  many  of  the  papers 
d^crib^  applied  research  results  or 
laboratory  simulation  status.  There  were 
the  exceptions,  primarily  in  the  diagnostic 
and  navimtion  arena.  Also,  a  USA  Navy 
program  tor  a  remotely  piloted  surveillance 
mission  that  contained  an  expert  system  for 
route  planning  is  to  be  test  flown  within 
the  next  year.  The  limited  number  of  real 
applications  presented,  ^ich  are  ready  to 
transition  to  operational  status,  is  an 
indication  that  the  technology  is  still 
imMitiue. 

In  response  to  the  four  themes  of  the 
symposium,  listed  completely  in  the  next 
section  of  this  report,  the  following  can  be 
co^uded: 

Response  to  Theme  (1).  Within  the  near 
future,  MI  will  (xobabiU  not  have  a  drastic 
impact  on  the  desiffi  of  aerospace 
electronics.  There  are  soma  exertions, 
sudi  as  the  USA  Navy  RIV  inxigran  previously 
mantionod.  In  the  far  term,  no  assessment 
can  be  made  until  awe  HI  programs  move  out 
of  the  laboratory  into  fligiit  test  and  pilot 
comments  esn  be  reviewed.  Programs  that 
include  thorough  verification  and  validation 
will  lay  the  groundwork  for  decisions  on 


transitionirg  the  tedmology  to  aerospace 
vdiicles.  llie  diagnostic  efforts,  such  as 
that  presented  by  Israel  for  ground 
maintenance,  will  likely  revolutionize  the 
future  of  supporting  aerospcu:e  operations, 
and  some  of  these  are  in  place  and  ready 
for  the  Logistics  Centers.  The  US  Adaptive 
Tactical  Ibvigaticxi  program  showed  that  MI 
could  provide  near  term  aid  to  the  pilot. 
The  maturity  of  the  US  ATN  and  the  Navy  RPV 
program  can  be  attributed  to  the  relative 
snail  size  of  these  efforts  and  limited 
complexity  of  the  systems. 

Response  to  Theme  (2).  Within  the 
aerospace  vehicle,  human  operators  control 
will  not  be  eliminated  by  the 
implementation  of  MI  in  aerospace 
electronics.  Routine  functions  can  be 
automatically  monitored,  as  discussed  in 
the  US  Pilot's  Associate  program,  where  the 
health  of  aircraft  system  is  continuously 
presented  to  the  pilot.  Also,  for  ground 
support,  the  use  of  MI  can,  to  some 
extent,  replace  some  human  operators.  An 
example  of  this  capability  is  presented  in 
the  paper  on  Advanced  Satellite 
Workstaticxi,  idiere  a  simple  rule  based 
system  has  provided  the  ca^ility  of 
removing  some  speciedists  from  the  support 
activity. 

Response  to  Theme  (3).  The  MI  programs  of 
the  future  will  provide  choices  tor  the 
pilot  from  idiich  he  makes  decisions.  Many 
of  the  papers  support  this  capability,  most 
notably  the  US  Pilot's  Associate,  ttw 
Britidfi  TACAID,  and  the  French  Coodnt 
Aircraft  Embedded  Expert  System  for  Real 
Time  Performance  Assessment  programs.  The 
papers  within  the  Core  Avionics  session 
were  among  those  papers  that  attest  to  MI 
capabiliw  to  provide  pilot  aiding  in  the 
future.  These  system  are  still  quite 
complex,  are  only  simulated  in  laboratory 
environments,  and  lack  real  tine  embedded 
electronics  that  are  necessary  before 
implementations  in  operational  aerospace 
vehicles  can  take  place.  Advances  in  MI 
systems  for  pilot  aiding  will  have  to  be 
introduced  gradually  to  win  pilot's 
confidence.  For  ground  su^rt 
operations,  the  use  of  MI  will  lessen  the 
training  needs  for  suqpport  personnel  and 
could  eliminate  many  siq>port  personnel. 

The  papers  in  the  space  and  diagnostics 
sessions  referred  directly  to  this 
capability. 
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Bespopse  to  Umbo  (4).  MI  vill  enable 
dccttaaic  fliyateM  to  oorxect  soae  faults 
and  aifavt  to  a  changing  enviroonent. 

Several  papers  addiassed  this  area  and  haive 
shom  tius  capability  in  siaulations.  Sane 
exanpLes  include  The  Integrated 
Ganeunlcations  Netvorfc  Frogcan  autonatically 
dunges  the  coanunication  nodes  to  naintain 
■isadw  capabilities,  the  Spacecraft 
Electrical  Power  Spsten  Fault 
Detection/Diagnosis  Prograai  and  the  Besource 
Manageeent  SfBtcn  Prograai  autonatically 
redistributes  the  power  in  a  qiaceccaft 
based  on  needs  eid  failures  occurring  in  the 
aysteai,  and  the  Ihtegcated  Coanunication, 
Navigation,  and  Identification  Avionics 
(IGmA)  Sj^tea  has  detected  96Z  of  all 
faults  and  isolates  90K  of  fnilts  to  a 
single  Line  Beplaceable  Module.  There  were 
other  papers  supporting  this  capability  of 
finding  faults.  Bowever,  if  inpleannted 
on-board  aircraft,  real  tiae  corrections  of 
faults  is  presently  United  by  the  speed  of 
on  board  processors  and  ardiitectures. 

Ground  fault  detection  and  isolation 
systens,  where  enbedded  processing  systens 
aren't  recpiired,  can  obtain  speeds  required 
for  real  tiae  operation. 

Since  expert  systen  and  knovleite  based 
systea  paradi^  were  essentially  the  only 
MI  technology  paradiga  presented  at  the 
syaposiua,  me  answer  to  the  motion  of 
deteraining  the  best  type  of  MI  paradigas 
that  are  suitable  for  a  vide  variety  or 
aerospace  electronics  applications  cannot  be 
nade.  Certainly  the  nature  paradipe  of 
eaqiert  systen  am  knowledge  based  systens 
should  be  continued  to  be  ajqilied  because  of 
their  success  in  nost  application  areas 
addressed  in  this  syaposiua.  The  applied 
research  papers  presented  give  nuch  fxipe  for 
neural  netvoiics. 


The  syaposiua  clear^  enphasized  various 
inportant  aspects  of  aacnlne  intelligence  in 
aerospace  electronic  systens: 

1.  There  are  high  eniectations  for 
aachine  intelligence  in  future  aerospace 
electronic  systens  in  all  of  the  areas 
addressed  by  this  sy^)osliBi.  The  use  of  MI 
should  solve  current  problens  in  activities 
like  real  tiae  satellite  control,  correcting 
fnilts,  providing  increased  pilot's 
situation  aMareness.  and  autoaating  ground 
support.  Those  with  respect  to  diapwstics 
«d  navigation  can  be  lapleaented  soon. 
Other  sore  coaplex  nystcas,  like  in  the 
pilot  aiding  arena  (as  deaonstrated  in  the 
Hint's  Associates  prograai,  require  aore 
iapravsamts  in  the  MI  temnolo^  and  in 
supporting  tedswlogies,  such  as  real  tiae 
pTxwessnri . 


2.  Thna  are  a  few  areas  where  aadiine 
intelligenoe  is  presently  iaplenanted,  but 
nost  activity  is  in  the  labcmtory.  Sone  of 
the  present  iapliaantations  are  in  the 
following  areas: 


a.  There  are  operational 
diapiostic  prograns  that  contain  MI  that 
are  providing  excellent  results,  decreasing 
eanpowet  needs,  reducing  training  needs, 
and  deteraining  faults  faster  thin  by  other 
aeans.  An  cxanple  is  in  the  Israel's 
diapwstic  prop»i  for  supporting  aerospace 
electronics. 


b.  Applications  in  the  navigation 
area  appear  aiinst  ready  for  operational 
imleaentation.  There  is  a  US  Navy  prograa 
for  BPV  vhidi  vill  fly  an  MI  systea  in  the 
near  future. 

c.  Progress  is  being  nade  in 
nission  planning:  however,  iaplenentation 
is  soaewnat  in  the  future  due  to 
require  amts  for  hi^ier  enbedded  processor 
speeds  and  a  need  for  an  inproved 
verification  and  validation  csqiability. 

3.  Real  tine  aH>lications  require 
iaproveaents  in  processors,  hardware,  and 
thmry. 


4.  Verification  and  validation  nethods 
need  to  be  inproved  so  that  the 
technologies  can  be  proven  to  voile  and  sold 
to  users. 

To  accelerate  the  inplenentations  of  these 
technologies  for  aerospace  electronic 
ai^lications,  the  kind  of  interactions 
be^  by  this  nyaposiua  between  the  AGARD 
countries  need  to  be  continued  and 
increased.  This  tedmology  is  very  coaplex 
and  all  countries  need  to  wild  on  the 
achieveaents  of  one  another  to  reduce  the 
developaent  tiae  and  costs. 

me  AID  cancnvBs 

Hie  title  of  this  syaposiua  was  "Machine 
Intelligence  for  Aerospace  Electronics 
^steas."  A  revolution  in  increased 
coaplexity  in  airborne  electronic  systens 
has  evolvw  to  counter  the  sq^stication 
of  threats  to  the  aircraft  and  to  locate 
and  attack  targets  in  real  tine.  This 
added  coiDlexlty  has  increased  the  already 
heavy  vorkload  of  the  aodem  pilots  that 
has  been  created  for  new  aircraft  design 
that  have  ever  increasing  aerodfynaaic, 
sensor,  and  weapon  capabilities.  The 
outgrowth  of  this  is  the  desire  to  lower 
the  pilot's  burden  and  to  Increase  his 
situation  awareness  by  using  increased 
autoaation,  systens  that  autonatically 
respond  to  non-essential  actions,  and  to 
provide  his  with  decision  aids.  Uiless 
this  autonoaous  capability  is  developed,  we 
can  expect  reduced  nission  effectiveness. 

In  addition,  weapon  systeas  readiness  and 
naintenance  are  ittoblens  that  liait 
availabili^  of  avionics  and  therefore, 
aircraft.  To  alleviate  these  {«obl«, 
snart  systeas  are  needed  that  have  the 
capabilities  to  adapt  and  reason  like 
hunans  and  to  repair  th  sea  elves  <»:  altigate 
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failure  throufi^  fault  tolerant  techniques. 
This  has  generated  the  current  vave  of 
activity  in  Hachine  Intelligoice  (MI)  to 
provide  these  needed  capabilities  for  the 
weapon  systeais  of  the  future. 

The  Avionics  Panel  developed  four  nain 
thenes  to  consider  for  this  synposim  to 
determine  the  maturity  and  uses  of  MI  for 
future  aerospace  electronic  ^tems: 

1.  MI  will  dramatically  alter  the 
design  of  aerospace  electronics  system 
because  MI  enables  automatic  or 
semi-automatic  operation  and  control. 

2.  For  mai^  routine  jobs,  MI  will 
totally  displace  human  operators. 

3.  For  other  situaticsis,  MI  will 
provide  screened  or  processed 
recoomendatims  for  courses  of  actions  to 
human  operators. 

4.  MI  %dll  liable  electronic  systems 
that  adapt  or  correct  for  errors,  and  many 
of  the  paradigms  promise  to  increase  the 
speed  or  response  to  near  re2d  time  through 
parallel  iiiq>lementations  or  use  of 
intelligent  algorithms. 

The  symposiw  vas  to  concentrate  on 
presenting  the  results  of  applying  MI 
technology  to  aerospace  electronics 
applications.  This  includes  focusii^  on 
determining  the  types  of  MI  paradigms  ^ich 
are  best  suited  to  the  %rLde  variety  of 
aerospace  electrcmics  a^M^Hcafions.  The 
panel,  in  the  call  for  rapers,  did  not  find 
an  overabundance  of  application  activities 
(since  most  of  the  activities  are  within  the 
research  arena)  from  which  to  chose; 
however,  there  was  a  sufficient  amount  of 
activity  to  report  from  each  uab&c  nation 
that  vas  it  vas  determined  worthwhile  to 
take  this  initial  look  at  the  technology. 
Another  problem  in  assessing  papers  for  this 
symposium  was  in  determining  which  papers 
reported  truly  MI  activities  versus  those 
that  reported  work  that  could  be  considered 
"clever  programing. "  This  is  a  problem 
that  the  MI  community  in  general  still  has 
not  resolved. 

For  this  symposium,  the  goals  were  to 
accurately  determine  the  current 
state-of-the  art  of  MI  applications,  to 
determine  the  system  areas  where  near-term 
pe^ffs  can  be  achieved,  and  to  define  vttere 
the  member  nations  should  put  emphasis  in 
the  future. 

■nrawrcAL  oowiair 

The  symposium  began  with  a  keynote  address 
fay  Philippe  0.  Bouchard,  Bri^ier  General, 
(CAF  (Retired),  who  is  the  Urector  of  the 
Center  for  Artificial  Intelligence 

licatlons,  in  Dayton,  Ohio,  USA.  He  set 
tone  for  the  meeting  by  strongly 


enphasizing  that  the  "hyps”  for  MI  systems 
is  over,  aM  that  "q;>portunities  are 
boundless  for  the  use  of  MI  in  avionics 
systems,  and  potential  implications  exist 
in  systems  diagnostics,  planning,  commend 
and  control,  intelligence,  fli{pt  and  fire 
control,  and  electronic  warfare."  He 
stated  that  events  of  the  Persian  Gulf  have 
changed  his  impressioi  of  the  state  of 
advmced  technology.  In  Operation  Desert 
Storm,  Artificial^telligence  has  shown 
it's  usefulness,  and  that  meidier  nation  Air 
Forces  need  to  maintain  the  technology  edge 

Sreseitly  enjoyed.  Fusion  of  all  available 
ata  will  be  a  critical  driver  for  future 
systems  if  air-crew  situation  awareness  is 
to  be  inmroved,  as  required  for  the  coiq>lex 
environmoits  envisions.  Machine 
Intelligoice  efforts  should  concentrate  on 
meeting  the  following  objectives:  improve 
training,  use  in  unmanned  flying  vdiicles, 
automate  diagnostics  and  replace  reliance 
(Ml  technical  manuals,  and  develop  systems 
that  are  aimed  not  so  much  at  enhancing 
technology  but  being  user  frieidly.  His 
predicticMi  vas  that  future  systems  will 
routinely  have  MI  incorporated  in  avicMiics 
systems;  however,  these  system  must  be 
cautiously  sold  to  the  users. 

He  acknowledged  that  US  D(X)  and  NASA  have 
invested  funds  in  many  aupplications 
relevant  to  avionics.  The  biggest  and  most 
cooqilicated  program  and  one  that  vas 
reported  in  this  symposium  is  the  DARPA 
sponsored.  Pilot's  Associate  Program.  Mahy 
other  less  complex  programs  are  Included  in 
nuBerous  US  programs,  and  some  are  included 
within  the  presentaticMis  here.  Mucdi  of  the 
HI  technology  has  advanced  to  the  point 
that  it  is  considered  a  software 
engineering  tool. 

Session  I  Oombd^  Control,  rciail  cations 
and  Information  (CH) 

The  papers  in  this  sessicMi  cover  the 
inportant  areas  of  mission  theater  control 
of  forces  and  surveillance  of  eMiny 
actions.  All  the  efforts  are  quite 
complex,  large,  and  are  being  evaluated  in 
the  laboratory.  Simulation  results  have 
shown  more  accurate  assessment  of  the 
battlefield  can  be  accomplished  with  the 
aid  of  MI. 

In  Paper  No.  1,  the  author  described  an 
Integrated  Coiaiunicati<xis  Network  (ICN) 
Management  System  (IMS)  to  allow 
integration  of  C3I  fimctions  that  are 
adaptive  and  survivable  in  a  dynamic 
environment,  to  support  strat^c  and 
tactical  opmtions.  This  IMS  provides 
reactive  capability  despite  enemy  efforts 
and,  in  addition,  provides  corrective 
responses  to  some  internal  systems 
failures.  The  IMS  ^tem  automatically 
initiates  surviving  resources  and 
determines  the  optimal  choice  of  end-to-end 
comiections  by  weighting  several 
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predetendiiad  decision  criteria.  It 
evaluates  conflicts  and  node  changes  to 
allow  for  ever-changing  user  needs  and 
operational  conditions  fddle  allowing 
reduced  operator  intervention.  The  IMS  is 
oi  intelllfnt,  syetce-vide  eanager  that 
autoeatically  ke^  the  coaeunicatlon 
networics  avallabu  for  satisfying  elssion 
requiieeents.  The  author  states  that  to 
obtain  the  integrated  netvorfci  the  resource 
eanager  requires  iaplenentation  of  MI 
techniques.  The  systee  will  be  prototyped 
in  a  luoratory  in  the  fall  of  1991.  At 
present,  the  systee  autoeatically  gives  the 
optieuB  solution;  however,  there  ^sts  a 
need  to  shorten  the  response  tine  and 
increase  the  bandwidth  of  the  systee. 


Session  II— Sjpaoe  Operations 

In  this  section,  the  papers  are  aland  at 
lowering  the  cost  and  liqiroving  the  control 
of  spaMcraft  fron  a  «ou)d  and  spaedwme 
perfective.  Since  the  spacecraft  is 
usually  without  a  huean  aboard,  the  use  of 
MI  is  vital  for  adaptable  operations 
required  to  accoanlisli  the  sission.  In 
addition,  a  Vey  oblective  is  for  MI  systean 
to  perfore  the  highly  technical  ground 
control  function,  for  anre  accurate  control 
and  the  reduction  of  the  need  for  as  laany 
hi^y  trained  <q>erators. 


Paper  No.  2  described  an  effort  to 
iapleaent  an  in-house  testbed  to  provide  a 
siaulation  of  an  operational  environannt  to 
validate  new  decislonHaaking  coanand  and 
control  (C2)  decisiori  aids.  Most 
in-laboratory  validations  of  these  aids  lack 
operational  realisa  and,  therefore,  give 
results  that  are  difficult  to  substantiate. 
Past  atteapts  at  a  decentralized  systea 
caused  bottlenecks.  This  led  to  a  modified 
blackboard  design  that  centralizes  data  and 
provides  easy  incorporatiem  of  new  data  and 
decision  aids  as  th^  becooe  available.  The 
current  systea  uses  an  Oracle  relational 
data  base,  an  intelligent  controller  for 
activating  decision  aids  when  needed,  and  an 
object-oriented  siaulation  to  allow  realism 
for  verification  and  validation.  Future 
efforts  will  use  a  distributed  object 
environaent  that  allows  decision  aids  to 
receive  and  send  information.  This  system 
allows  implementation  of  loosely  coupled 
designed  decision  aids  in  a  realistic 
siaulation  environment.  Interoperability 
and  evaluation  is  required  before  this 
system  could  be  fielded  in  a  cooqxysite 
operational  system. 

Paper  No.  3  discussed  a  method  of  producing 
oure  realistic  route  planning.  Effective 
route  planning,  to  counter  threats,  is  a 
requirement  for  future  odssion 
accoeplishaants  and  survivability,  but 
present  methods  do  not  consider  all  the 
elements  necessary  to  ensure  success.  A 
program  called  "Beuristic  Route 
Optimization''  (BERO)  uses  Object  Oriented 
Prograaaing  to  produce  route  planning  that 
takes  into  account  many  factors  that  other 
programs  do  not.  These  variables  include 
specific  airfraaes,  tactics,  multiple 
sorties,  threat  connectivity,  «id  alert 
status.  The  BERO  prograa  collects  threat 
information,  dctomlnes  and  st<nnes  costs  of 
encountering  targets,  aid  performs  an  A* 
search  to  obtain  lownt  cost.  The  prograa 
can  be  indlfled  dynamically  as  required. 

The  eystern  produces  a  mission  path  plan, 
that  althoupi  mqr  not  be  optimum, 
neverthelass,  ;n:oduoes  a  good  route  with  low 
lethality  and  cost.  This  tool  is  capable  of 
plaming  multiple  sorties  responding  to 


In  Paper  No.  4,  the  Advanced  Satellite 
Workstation  (ASW)  is  investigating  the 
utility  of  es^rt  systems  in  a  sla|>le  rule- 
based  systea  for  the  attitude  control  of  a 
military  satellite.  IhreL  goals  were 
established  for  the  program:  (1)  Reduce  the 
cost  of  ground  control,  especially 
manpower;  (2)  Reduce  the  number  of 
specialists  needed;  and  (3)  Automate 
operator  tasks.  Satellite  information  was 
gathered  from  factory  esqoerts  and  from 
flight  data  to  make  the  knowledge  base  for 
the  system.  The  expert  system  detects 
probleas  and  offers  solutions  and/or 
automatically  recalls  appropriate  factory 
information  to  better  understand  the 
problem.  Linking  the  system  with  a  main 
Coanand  and  Control  l^stem  provided  a  means 
to  evaluate  the  systems  performance.  A 
demonstration  and  report  have  been 
accomplished  for  this  low-cost  program. 


Paper  No.  5  discussed  human  reasming  and 
an  attempt  to  develop  a  system  capable  of 
human-like  reasoning  for  euitonomous 
satellite  control.  At  the  present  time, 
there  are  4000  individuals  supporting  80 
satellite  systems.  By  the  year  2000,  there 
will  be  135  satellites.  This  prcMram  has 
as  it's  intent  the  reduction  or  ^  nuid)er 
of  personnel  required  while  improving  the 
accuracy  of  control.  Ovians  rely  on  many 
different  reasoning  techniques  to  solve 
problems,  and  this  program  is  integrating 
many  of  them.  The  system  uses  a  blackboard 
architecture  for  blending  the  various  kinds 
of  reasoniiv  through  numerous  reasoning 
ondules.  The  modular  partitioning  of  the 
system  is  based  on  reasonii^  meth^lor*^ 
rather  than  the  usual  knowledge  categories. 
The  nystem  produces  a  synergistic  effect 
thnn^  the  blackboard  that  solves  problems 
not  solvable  by  any  individual  oudules.  The 
addition  of  leeuming  feedback  allows 
updates.  Fhture  extensions  will  add  oure 
reasoning  modules  and  provide  a  feedbadi 
nystem  to  the  modules. 


Paper  No.  6  described  a  fault  detection/ 
diagnosis  and  resource  management  system 
for  spacecraft  or  space  system  electrical 
power  control.  Ground  baaed  monitorii^  and 
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control  o£  space  vehicles  has  become  more 
demanding  due  to  low  intersect  tines.  Thus, 
a  requireannt  for  a  more  automated  system 
vas  needed.  The  author  discussed  the 
various  costs  and  etpiipnent  capabilities  of 
automation  in  space  as  compared  to  on  the 
ground.  One  particularly  critical  ^ten  is 
the  control  and  monitoring  of  the  electrical 
power  nystem  (GPS) .  An  Ai  system  was 
develop  to  better  distribute  the  power 
after  determining  faults  in  either  the  space 
vehicle  or  the  ground  system.  The  critical 
element  of  this  system  is  the  model  based 
fault  module  that  determines  emergency 
responses  in  real  time  and  provi^  ii^t  to 
the  mo^  based  diaoiostic  nodule.  The 
system  is  capable  of  isolating  failed 
components,  and  provides  input  to  an 
adaptive  planner  that  ke^  a  file  on 
successful  operations.  At  the  present  time, 
an  integrated  Fault/Planning  system  is 
implemented  and  trill  be  connected  to  a  large 
space-breadboard  EPS  for  Space  Based  Radar 
operation.  The  next  phase  will  demcmstrate 
the  resulting  radar  power  control  system. 


Session  HE— Offensive/Defensive  Sjysb 
ELectronics 


The  papers  of  this  section  covered  a  broad 
ran«  of  complexity  and  applications 
including  mission  planning,  automatic  target 
recognition,  and  electronic  countermeasures. 
Although  th^  programs  are  laostly  in 
laboratory  evaluation,  th^  nevertheless 
demonstrate  the  power  of  la  to  help  solve 
critical  aerospace  electronic  application 
problems. 


system  uses  a  stored  knowledge  base, 
selects  relevant  experiences,  and 
extrapolates  them  to  the  current  situation 
to  produce  the  best  recoamendation  for 
countermeasures  response.  Two  types  of 
data,  signal  and  kinematics,  form  the  basis 
foiT  the  analysis  and  are  us^  to  calculate 
survivabili^.  New  knowledge  can  easily  be 
added.  The  system  makes  use  of  various 
machine  intelligence  and  processing 
technologies  si^  as  parallel  processing, 
fuzzy  sets,  neural  networics,  and 
optimization. 

Paper  No.  9  provided  an  overview  of  neural 
processipg  techniques  and  their  potential 
applications  in  functions  suoi  as: 
tracking,  deinterleaving,  emitter 
identification,  and  tactical  situation 
analysis.  As  radar  parameters  become 
hij^:^  in  fremiency  and  more  coimlex  in 
g«eral,  a  radically  new  method  is  required 
to  accomplish  the  functions. 

Therefore,  a  neural  networic  system  was 
developed  and  evaluated.  Neural  networks 
are  useful  to  solve  the  emitter 
identification  problem  due  to  increased 
density  and  complexity  of  emitters  both 
friendly  and  eneiy,  and  new  war  mode 
parameters.  Results  were  shown  from  a 
proflpram  using  probabilistic  neural  networks 
to  discriminate  targets  in  elevations  with 
multipath  present.  The  system  is  very 
promising;  however,  a  few  problems  rei^n 
such  as  growth  of  the  neural  network, 
excessively  long  training,  and  no  link  to 
history  of  responses.  Hardware  is  being 
developed  to  make  implementation  possilue. 


Paper  No.  7  described  an  effort  by  British 
Aerospace,  called  "TACAZD,"  to  embed  Al 
into  future  fighter  aircraft.  Earlier,  work 
was  reported  to  AGARD  on  the  use  of  Al  in 
mission  planning  in  a  one-on-many, 
air-to-air,  beym-visual-range  s^tem. 
Presently,  they  are  working  on  the  TACAID 
prototype  to  e9q>lore  the  use  of  hifl^  level 
heuristic  reasoning  to  produce  (q>tlmum 
steering  and  firing  cues  for  tactical 
situations  for  single  seat  aircraft  engaging 
targets  beyond  visual  range.  This  systea 
includes  artificial  intelligence  along  with 
conventional  algorithms.  The  TACAID 
utilizes  heuristics  within  an  AI  tool  called 
'WSE”  and  has  been  isplemented  on  a  Sun 
work  station.  Results  show  that  this 
knowledge  representation  is  flexible  and  can 
be  updated  easily.  FViture  efforts  dealing 
with  uncertainty  and  real  time  may  require 
neural  networks. 

Paper  No.  8  discussed  an  artificial 
intelligence  aystcm  approach  that 
automatically  reco— ms  countermeasures 
against  threats  hy  performing  analysis  of 
siffiature  intwxepts  without  direct 
idmtification  of  the  threat.  The  objective 
of  the  system  is  to  rscommend  countermeasure 
responae  idille  ecconodating  imperfect  data 
and  crrora  in  situation  assessment.  The 


Paper  No.  10  discussed  a  research  activity 
looking  at  cooqxiting  optimal  aircraft 
trajectory  in  real  time  that  increases 
survivability  and  mission  effectiveness  and 
minimizes  radar  exposure  when  encounterit^ 
enemy  threats.  The  normal  methods  of 
solving  this  problem  require  airborne 
processors  with  greater  than  30  HIPS 
capability,  ^cn  are  not  available  at 
present.  An  analogous  program  is  solved 
using  electromagnetic  fields  looking  at 
scaler  field  theory.  A  massively  pandlel 
neural  network  architecture  is  defined  that 
solves  the  resulting  second  order  partial 
differential  equations  while  providing  real 
tine  operation.  The  esqierimental  neural 
network  system,  based  on  the 
electromagnetic  analogy,  has  produced  good 
path  solutions. 

Paper  No.  11  presented  results  from  using 
neural  networks  for  automatic 
classification  of  air  targets  in  infrared 
imagery.  The  system  has  two  nodes;  one 
includes  an  operator  and  the  other  is 
automated  with  neural  networics.  The  four 
layer  bade  propagating  neural  network  is 
trained  using  real  data.  This  network 
allows  good  ceco0altion,  hi|^  speed,  and 
rapidly  learns  new  data.  Hardware 
isplenentation  of  the  vector-matrix 


TER-6 


■ultlpllcatlon  classification  systai  is 
easily  accoaplisiied.  The  neural  network 
^tes  obtained  90K  correct  classification 
on  all  types  of  targets  or  buildings, 
whatevo:  their  orientation  or  distance,  on 
any  bad(gcaund>  Beal  tine  hardmre 
iinlaKntation  of  the  neural  network  is 
bung  attenpted  at  the  present  tine. 

Paper  No.  12  stated  that  in  hostile 
environnents.  the  Angle  of  Arrival  (  ADA)  is 
the  key  sorting  paraneter  for  Badar  Uaming 
Receivers  due  to  its  stability  over  tine.  A 
no^  phase  interferoneter  that  neasures  AOA 
note  than  ten  tines  better  than  standard 
systens  was  described.  The  AOA  allows 
threat  localization  with  increase 
perfomance  by  the  aircraft  throng  threat 
avoidance.  Since  the  Etf  problen  Is  a  natter 
of  decisions  over  tine,  snart  reasoning  is 
required.  That  requirenent  led  to  the 
inclusion  of  the  "^Siffi"  expert  systen. 

This  systen  provides  threat  nodeling, 
reasoning,  anbigulty  detemination,  and 
heuristics  for  threat  avoidance.  Future 
systens  will  include  neural  networks  for 
prefiltering.  The  author's  view  is  that 
using  neural  networks  for  tine  integration 
would  be  difficult. 

Session  IV— Irrigation  Spstcai  Bto:trQnlcs 

Applications  of  MI  to  aerospace  navigation 
electronic  systens  is  close  to  being 
available  for  iaplenentation.  This  was 
verified  in  the  papers  of  this  session. 
Results  idbowi  were  nost  encouraging.  The 
reason  for  this  naturity  is  lar^y  due  to 
the  snaller  size  and  the  lack  or  coaqrlexity 
of  these  applications. 

In  P^per  No.  13,  the  author  discussed  the 
attei^f  to  iapienent  a  real  tine  Knowledge 
Based  ^ten  for  an  autopilot  for  a  generic 
high-perforaance  aircraft.  The  first  try 
using  CLIPS  progranning  language  and  was  too 
slow  and  thmfore,  unsuccessful.  A  new 
ioqrlenentation  using  a  Fortran  Library  for 
Eamert  Systen  Developnent  (FLEX)  provided  an 
order  or  nagnltude  iaprovenent  in  speed  and 
satisfactory  operation.  Prelininary  results 
suggest  that  ttiis  systen  is  capable  of  real 
tine  pilot  aiding.  The  efforts  include  a 
heavy  enphasis  on  the  verification  and 
validation  of  a  real  tine  Knowledge  Based 
autopilot. 

Paper  No.  14  reviewed  the  results  of 
inserting  Artificial  Intelligence  into  a 
navigation  qysten  desigpied  for  tactical 
aircraft.  Fhture  airdwt  require  hia^ 
accuracy  navigation  data  for  stand-ofx 
weapon  delivery,  terrain  following/ terrain 
avoidance,  and  nl|dtt-in.weather  operation. 
Tha  systen  develop  was  naned  the  Adaptive 
Tactical  Navigation  systen  with  the  purpose 
of  aelecting  tha  beat  source  of  navigation 
data  fron  nine  different  possible 
coiripinetlona  of  sensor  in^ts.  The 
knowledge  included  was  ga^ered  by 


interviewing  nany  pilots.  A 
denonstration  in  an  P-16  dene  sinulation 
facility  was  successfully  accoaplished. 

The  remits  showed  that  the  \tae  of  an  ATN 
systoi  could  reduce  navimtion  errors,  and 
the  crews  preferred  the  Interaction 
provided.  The  results  and  experiences 
during  this  project  indicated  that  such  an 
inteUigent  systen  onnager  could  produce  a 
neasuraSle  bmefit  in  the  real  world.  With 
the  inclusion  of  sore  knowledge  and  better 
sensors,  the  benefits  of  an  Koi  systen 
should  ia^rove. 

In  Paper  No.  15,  the  author  has  developed 
an  al^rithn  to  inprove  the  reliability  of 
aircraft  inertial  navigation  aystens  (INS) 
usii«  neural  network  software  siaulations 
to  Bodel  mtenatic  errors  in  attitude 
outputs.  This  neural  network  systen,  after 
training,  produces  the  correct  attitude 
output  und^  alnost  all  circunstances.  The 
him  point  of  this  apsten  is  the  use  of  a 
"iackmfe''  training  algorithn.  With  this 
algorithn,  training  does  not  increase 
eqxmential^  with  the  mmber  of  training 
eaaq>les.  This  training  Kthod  produces  a 
nearest  neighbor  neural  network  that  is 
"well  behaved”  doesn't  deviate  fron  the 
training  data,  and  therefore,  provides  the 
needed  reliabiliW.  The  siaulations  were 
evaluated  using  flight  test  data  fron 
sanpled  INS  data.  Locally  linear  and  back 
propagation  neural  netwoncs  were  used.  The 
results  using  the  flight  test  data  provided 
two  nilliradlans  accuracy  with  five  inputs 
fron  heading,  pitch  and  roll  sensors. 

Session  V— Gore  Electronics 

The  papers  of  this  session  exclusively 
cov^ed  the  application  of  MI  to  pilot 


aiding  and  codq>it  situation  awareness  in  a 
single  seat  aircraft  perforning  a  tactical 
nlssion.  The  DABPA  sponsored  "Pilot's 
Associate  Progran”,  the  largest  and  nost 
conplex  US  MI  prograa  targeted  for  aircraft 
application,  was  reviewed  in  this  session. 
All  of  the  efforts  described  in  the  papers 
are  laboratory  siaulations  that  show  vast 
iB|>rovenents  for  the  cockpit.  However, 
real  tine  operation  and  verification  and 
validation  are  problens  that  nust  be 
resolved  before  serious  iaplenentation  can 
take  place. 

Paper  No.  16  described  the  USAF's  attenpt 


systen  called  the  "Pilot's  Associates 
Prograa."  Two  contractors,  with  different 
flight  scenarios  and  nission  requirenents, 
were  included.  The  progran  would  not 
rmlace  the  pilot  but  would  aid  hin.  A 
video  was  diown  that  explained  the  aysten, 
denonstrated  how  the  5  expert  systens  nli^t 
interact,  and  depicted  the  disjuays 
possible  fox  pilot  viaring.  The  paper 
discussed  the  four  phases  of  the  progran. 
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getting  to  the  real  tine  capability  to  be 
shown  in  their  Demonstration  4  during  1992. 
Present  activities  are  trying  to  get  real 
tine  perfomance  and  inplementation  on 
nulti-chip  nodules  with  co-processors.  The 
program  httl  breakthrou^  in  the  following 
areas:  evaluation  of  large  complex  AI 
system,  proven  rapid  prototyping  as  an 
effective  tool  in  ^tem  de^opment,  and 
the  translation  of  IJSP  into  Am.. 

In  Paper  No.  17,  this  British  program  is 
focusM  on  aiding  the  single  seat  pilot  by 
making  tactical  Vision  aids  availwle. 
These  aids  are  required  to  increase 
performance  and  decrease  workload.  This 
work  addressed  both  the  offensive  and 
defensive  the  air-to-air  condiat  role  of 
nodem  fighter  aircraft.  Situation 
assessment  algorithms  were  shown,  along  with 
associated  coaq[>it  displi^.  This  psq>er 
outlined  the  work  and  achievements  to  date 
and  provided  informed  <minlon  regardii^  the 
further  development  of  Tactical  Declsi<xi 
Aids.  It  discussed  difficulties  with  the 
inqileaientations  including  the  nonexisteice 
of  a  small  air-worthy  computer  system, 
difficulty  of  obtaining  a  practical 
solution,  and  for  a  generic  problem  what  is 
the  right  or  optimum  soluti<xi.  Future  work 
must  ^ress  r^  time  operaticxi  and 
achieving  maximum  performance  with  minimum 
woricload. 

Paper  No.  18  also  discussed  the  copmlexities 
caused  by  single  seat  aircraft  in  the 
sophisticated  environments  existing  or 
e)q«cted.  The  author  discussed  the 
development  of  a  Mission  Management  Aid 
using  AI  that  fuses  many  of  the  data  sources 
available  to  the  pilot  to  make  decisions, 
from  taking  care  of  "house-keeping”  to 
determining  (^timum  fli^t  plans  using  the 
fusion  of  sensors  and  data  available. 
Problems  exist  in  understanding  the  pilot's 
information  requirements,  how  to  best 

f  resent  the  data,  and  putting  expert  systems 
nto  conventional  computers.  Their  next 
step  will  be  an  atteaq)t  to  develop  a 
dedicated  "translation"  of  this  eiqpert 
system  into  a  "conventional"  real  time 
language  on  a  conventional  processor. 
Finally,  he  discussed  the  serious  problem  of 
validating  the  system. 

Paper  No.  19  stated  that  due  to  the 
cciqilexitles  of  future  aircraft  and  single 
seat  aircraft,  advanced  aids  are  required 
for  achieving  mission  success.  This  program 
provides  mission  management  aids  by  fusing 
many  assorted  data  inputs  for  an  air 
Interdiction  mission.  These  aids  are 
required  due  to  increased  fighter  speeds, 
increasing  number  of  cockpit  systems  and 
displays,  md  Increases  in  the  number  of 
sensors.  This  system  generates  an  <^tinum 
flight  plan.  In  addition,  the  ptoeran 
automatically  takes  care  of  general 
housekeeping  functions.  Great  care  is  taken 
to  understand  the  pilot's  information 


requiremeits  and  displi^s  for  ease  of 
comprehension.  Finally,  the  system  must  be 
validated.  The  current  status  of  the 
system  is  that  there  will  be  a  simulation 
run  in  the  laboratory  in  the  near  futiu%. 

A  flyable  system  will  not  be  available 
until  the  year  2000. 


F£q)er  No.  19a  presented  a  program  for 
implementing  an  AI  system  for  the  control 
of  an  R^tely  Piloted  Vehicle  (RFV).  The 
targeted  RFV  program  does  not  have 
man-aided  gtound  control  and  does  not  carry 
weapons.  The  system  combines  AI  expert 
systems  with  reed  time  control  to  perform 
route  planning  for  ocean  surveillance.  The 
system  called  "Sensor  Driven  Airborne 
R^lanner"  (SOAR)  uses  the  camera  system  to 
determine  for  current  azimuth  and 
elevation,  and  the  focal  leigth  of  the 
system  to  determine  latitude,  longitude, 
and  size  of  the  ship  under  observation. 
Based  on  the  response  of  the  SOAR, 
autopilot  comnands  are  generated  for 
navigation  of  the  RFV  to  the  best  positirai 
for  the  mission.  A  laboratory  simulation 
proved  that  the  system  could  accooplish  the 
mission.  Overall,  the  program  has 
developed  the  inference  ei^ne,  rules, 
sensor  input  requirements,  smart  autopilot, 
and  successfully  integrated  all  conqxxient 
parts. 


In  Paper  No.  20,  a  Tlueat  Management  8vstem 
(TMS)  was  described  that  addresses  the 
planning  phase  of  a  penetrating  bomber 
mission.  The  prototype  develc^ed  provides 
in-fli|^t  situation  awareness,  terrain  and 
threat  avoidance,  and  tactical  a^ice. 
Prefli^t  mission  plans  are  developed  from 
electronic  order  of  battle  and  ground  order 
of  battle  information.  The  results  of  this 
prefli^t  plan  is  to  automatically  conqiute 
optimal  flight  paths.  The  system,  when 
airborne,  motors  the  actual  situation  and 
replaces  the  mission  plan  as  required  due 
to  changes  in  the  environment,  using 
knowledge  about  own  capabilities  and  those 
of  the  enenw.  The  threat  scenario  is 
determined  by  using  the  sensor  data 
received  and  the  stored  knowledge  base.  In 
the  future,  a  digital  map  capability  trill 
be  included  along  with  real  hardware. 


Session  VI— Diagnostics 

The  following  pcqpers  dealing  with 
diagnostics  revved  a  most  mature  area  of 
MI  imlication.  The  most  successful  uses 
of  Ml  in  the  expert  system  area  outside  the 
military  are  already  well  defined  for 
diagnosis  in  medicine,  cataloging, 
ordering,  and  inventory.  The  success 
shown  in  these  papers  using  MI,  therefore, 
comes  as  no  surprise. 


Paper  No  21  discussed  the  fact  that  one 
half  of  the  costs  of  operating  coafaat 
aircraft  is  due  to  maintenance  problems. 
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To  lower  this  cost  requires  that  the 
■aintenance  be  accoe^died  in  the  future  as 
a  two-level  systea  (field,  d^t  levels). 

The  objective  is  to  autoeate  the  trouble 
shooting  and  to  provide  non-aebiguous  fault 
detection.  The  use  of  A1  greatly  aids  this 
two  level  concept.  However,  the  first 
studies  have  shown  that  AI  by  itself  does 
not  solve  the  problen,  but  nust  be  coadiined 
with  a  eore  global  philosophy.  The 
procedure  is  to  inv^tigate  the  ^tee  fron 
an  integrated  eaintenance  concept  by 
checking  the  integrity  of  hardwiure  and 
software  coefwnnts  or  functional  chains. 
Intelligent  eachines  say  be  used  at  various 
stages:  real  tine  during  nission  and  fault 
detection  at  the  intemediate  shop  and  at 
the  d^Mt.  An  MI  systen  is  expected  to  be 
fielded  as  a  full-iq>  ^ten  fay  1997. 

Results  to  date  show  that  MI  is  well  suited 
for  diagnostics.  The  systen  caad>ined 
techniques  for  best  re^ts  yielding  a 
^sten  that  detected  96Z  of  all  faults 
\nthin  60  minutes. 


Paper  No.  22  described  an  Expert  Eysten 
culed  "  TOBRES"  that  id«tifies  and 
isolates  faults  that  occurred  during 
previous  flij^ts.  This  is  determined  during 
post  fillet  ground  checkout.  The  present 
systea  checks  the  Tornado  nose  radar  systen. 
With  the  increased  identification  of  raults 
by  this  system,  the  time  and  cost  of 
performing  maintenance  has  been  greatly 
reduced.  This  has  been  accomplished  d^pite 
the  increasing  conplexity  of  this  aircraft. 
This  system  also  provides  accurate  debriefs 
on  the  cause  of  mlure,  allowing  increased 
learning  fay  the  personnel  in  cham  of 
maintenance.  Thm  is  a  need  to  Include  all 
of  the  electronic  systens  on-board  the 
Tornado  and  not  Just  the  radar.  The  present 
systen  runs  on  either  a  PC  or  a  Symbolics 

Srocessor.  A  three  to  four  times  speed 
nprovenent  is  achieved  ^dien  using  the 
SyiKx>lics  processor. 

In  Paper  No.  23,  an  expert  systen  decision 
aid  for  assistiiv  in  aircraft  maintenance 
was  described.  The  system  handles  large 
scale  units  under  test  (UUT)  that  contain 
both  analog  and  digital  electronics, 
hydraulic,  and  nedianical  U)dules.  The 
system  identifies  faulty  nodules, 
determines  the  optimun  test  seouence,  and 
learns  fron  e3q>eriences.  The  diagnostic  and 
test  sequenciiw  algorithn  proves  the 
potential  of  lu  to  perform  cquipannt 
troubleshooting.  Tne  systen  is  being  used 
q[>erationally  at  the  present.  The  old 
method  of  doing  this  type  of  maintenance  was 
to  have  numerous  diagnostic  charts  with 
step-fay-step  instructions  that  led  to 
numerous  possible  faults.  This  method, 
using  AI,  eliminates  the  diigpfiostic  charts. 
The  systen  displays  pictures,  schematics, 
timing  tables,  mtid  color-codM  data  showing 
states  of  pertomanoe.  This  systen  allows 
quick  testing,  doesn't  require  hl^y 
trained  personnel,  and  also  includes  various 


siqtport  tools. 

Paper  No.  24  presented  a  knowledge-based 
assistant  for  diagnosis  in  aircraft 
maintenance.  Often  in  the  maintenance  of 
aircraft,  the  dianiosis  is  the  bottlenedc 
in  achieving  timelv  and  inesqiensive 
r^iairs.  Lessons  learned  are  easily  added 
to  the  knowledge  base.  At  the  present,  the 
program  is  aiamd  at  identifying  probleu  in 
the  air-conditloniog  systea  of  transport 
aircraft.  Since  the  air-conditioning 
system  is  distributed  over  the  aircraft  and 
since  components  are  not  directly 
accessible,  there  is  no  single  test 
procedure.  The  AI  systen  i«ntifies 
problems  using  synthesis  to  determine  cause 
and  using  past  experiences  and 
observations,  hypothesizes,  and  symptoms  to 
recoMend  solutions.  Sow  of  the  elements 
that  cause  diagnosis  bottlenecks  include 
incomplete  complaint  information,  poor 
docuBientation,  Isudt  of  complaint  history, 
and  lack  of  feedback.  The  KBS  will  specify 
tests  and  various  maintenance  activities 
that  should  solve  the  problems.  So  far, 
the  system  has  been  validated  in  the 
laboratory.  The  next  stage  is  to  build  a 
prototype  system.  VIhat  has  been  shown  is 
that  a  RBS  maintenance  aiding  system  can 
perform  diagnosis  and  transform  results 
into  specific  tests.  Past  experiences  are 
identifiable  and  formalized  within  the  KBS, 
and  within  a  limited  scope,  the  system  was 
successfully  demonstrated.  Lack  of  adequate 
complaint  information  is  still  a  problen. 

In  Paper  No.  25  a  systea  was  described  to 
isolate  faults  to  one  or  more  modules  in  an 
Integrated  Communication,  Navigation,  and 
Identification  Avionics  (ICNIA)  system. 

The  internal  expert  system  provides  a  more 
reliable  and  fault-tolerant  systea.  The 
system  uses  built-in  tests  and  analysis  of 
the  airborne  configuration  to  isolate 
faults.  The  author  showed  pictures  of  the 
advanced  development  model  of  the  systea. 
The  software  is  in-flijht  reconfigureable 
to  work  around  faults.  The  systen  allows 
detection  of  96X  of  all  faults,  isolates 
90K  of  the  faults  to  an  Line  R^lacable 
Module,  IBM,  or  isolates  95!C  of  the  faults 
to  two  LRMs.  The  systen  uses  Built-in-Test 
as  the  data  collection  mechanism  for  the 
expert  system.  The  payoff  is  increased 
operational  availability  and  improved 
supportability. 


Paper  No.  26  dealt  with  the  use  of  MI  for 
software  supportability.  Advanced  avionics 
systens  execute  vast  amounts  of  Ada 
software  on  multiple  parallel  computers. 
Avionics  software  support  occurs  after  the 
software  is  fielded  at  the  Logistics 
Centers.  Maintenance  of  coaq>lex  software 
involves  many  people.  The  majority  of  the 
cost  to  avionics  software  systens  is 
attributed  to  the  software  sumrt  area. 
Correction  of  deficiencies  and  the  addition 
of  eriiancmaents  require  much  tine  for 
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searching  and  infercncing  of  infonation. 

The  real  pcoblei  is  that  audi  of  the 
developMnt  knowledge  is  not  available.  The 
systaa  described  uses  HI  to  transfer  this 
knowledge  to  the  user.  The  support  systea 
developed  assists  in  tieely  placoeont  and 
organisation  of  changes  to  the  softwre.  It 
uses  a  rule  based  systee  and  senantic 
networks  to  ooaeunicate  to  the  user. 


Session  ?II— Ocneric  Techwlogy 

The  papers  in  this  session  cover  note 
genial  areas  of  possible  aerospace  araten 
The  specific  MI  technologies 
areas  of  concern  are  quite  diverse.  These 
papers  provided  a  nost  interesting  close  to 
the  sy^posiuB. 

Paper  No.  27  detailed  the  results  of  a 
costive  study  looking  at  AI  techniques  to 
iaprove  the  aan-aadiine  interface  for  C3I 
systeas.  This  study  vns  required  because 
most  of  the  AI  research  for  C3I  focused  on 
inprovenents  in  the  besic  concepts  of 
infomation  transaission  and  al^rithas  to 
iaprove  the  identification  process  but,  did 
not  consider  the  equally  iarortant  part  of 
interface  to  the  operator  through  a  graphics 
display.  Two  decision  aids  have  been 
dev^(g)ed:  the  Tactical  Expert  Mission 
Planner  (TEMPLAR)  and  the  identification  of 
Coanand  and  Control  Operations  Nodes  (ICON). 
The  TEMPLAR  systen  is  an  expert  sfystea  usii^ 
frane-based  reasoning.  The  ICON  systen  is  a 
blackboard  enbedded  systen.  The  techniques 
tried  were  adopted  fron  the  entertainnent 
and  advertising  coansiity.  The  study 
assuned  that  the  required  data  were 
available  and  that  processing  power  of  the 
future  will  handle  these  future  denands. 

The  graphical  representations  apply  to  the 
tactical  C3I  donain  and  include  aission 
scheduling  enhancenents  to  aninte  a 
situation  assessnent  nap  over  tine.  These 
presentations  are  understood  at  a  glance  and 
give  the  operator  a  better  understanding  of 
the  situation.  The  systen  proved  to  be  very 
user  friendly  and  the  graphics  enhanced  the 
effectiveness  of  using  MI  techniques. 

In  Paper  No.  28,  a  graphics  tool  titled 
"fivloserlng  Graphic^  Analysis  Tool”  (BGAT) 
was  described  that  provides  the  user  with  a 
single-step  capability  to  identify 
bottlenedcs  or  incorrect  paraneters  in  an 
activation  frane  architecture.  Fron  the 
Advanced  Tactical  Navigation  Siraten  progran 
described  earlier  in  uils  session,  it  was 
found  that  the  activation  franswork 
architecture  had  problaas  setting  the 
control  settinfi  and  interacting  between  the 
AI  and  conventional  systens.  It  was 
extranaly  difficult  to  perfom  verification 
and  validation  of  the  knowlete  base.  BGAT 
was  the  tool  developed  to  deal  with  these 
{HPoblens  arising  in  the  activation  framework 
architecture.  The  graphics  interface 
displays  the  interactions  anong  all  levels 


of  the  various  activation  frane  groups. 

The  user  can  <hmaadcally  nodify  parameters 
to  determine  their  effect  on  the  systen. 
This  greatly  reduces  the  effort  and 
increases  the  accura^  of  aanual 
interpretation.  Future  work  is  expected  to 
translate  the  system  into  ADA  language, 
incorporate  parallel  processing,  and  fully 
develop  the  knowledge  base  for  verification 
and  validation. 

Paper  No.  29  discussed  a  knowledge-based 
ac^sition  systen  developed  for  the 
Canadian  Space  Agency  using  the  ACOtOBB 
expert  systen  shell.  The  system  allows 
the  users  to  rapidly  develop  their  own 
esqwrt  systen  knowledge  bases  and  convert 
then  for  use  in  task-oriented  training. 

The  system  has  a  learning  nodule  that 
natches  the  user's  knowledge  data  base  with 
an  expert's.  Another  nodule  evaluates  the 
user's  acconplishnents.  The  progran, 
written  in  C,  is  aM>licable  to  crew 
training  problems.  Results  have  confimed 
that  the  tools  provide  a  practical  neons  of 
utilizing  existing  industrial  personnel  to 
construct  complex,  autonated  training 
courses.  Exp^ences  gained  should  meet  a 
broad  range  of  training  nee^. 

In  Paper  No.  30,  problems  with  reasoning 
with  inconplete  and  uncertain  infomation 
for  application  to  aerospace  electronic 
systems  were  discussed.  Many  of  the 
decisions  to  be  made  in  an  aerospace 
vdiicle  suffer  fron  not  having  complete 
data  and  uncertainties  within  the  available 
data.  The  author  stated  that  MI  was  harder 
than  researchers  were  led  to  believel  Some 
applications  are  being  accomplished; 
however,  further  progress  is  hindered  by 
lack  of  verification  and  validation  of 
perfomance  of  MI  inplenentations.  For 
reasonli^  with  inconplete  and  uncertain 
data,  the  Deapster-Sdiaefer  and  Bayesian 
nethods  were  described.  It  is  tricky 
setting  the  probability  Units  for  these 
uncertainties. 


BOOOMWMnCHS 

There  should  be  another  syaposiun  in  two  or 
three  years,  which  should  include 
presenters  from  this  syaposiun  reporting 
on  their  progress  as  as  new  pamers  and 
presenters.  A  lecture  series  should  be 
conducted  on  HI  technology  and  applications 
to  aerospace  electronic  systens  to 
disseminate  MI  research  findings  anre 
rapidly. 

This  synposiun  concluded  that  future  MI 
applications  should  be  accelerated  for 
amaller  and  siapler  aerospace  electronic 
systean.  The  relative  high  degree  of 
naturity  of  this  type  of  applications 
reported  here  attests  to  this  conclusion. 
Certain^,  prograns  ained  towauxis  the  anst 
successful  applications,  such  as  navigation 
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and  diacpiostics  systeast  should  be 
accelerated  to  iapleaantation.  If  this  is 
done,  the  continuu  success  vith  these  less 
risky  applications  vould  Isy  the  groundwork 
for  the  appEOval  of  larger  systea 
applications  in  the  future.  Also,  in  these 
d^  of  declining  defense  budgets,  these 
ty^  of  siapler  application  are  aore 
fordable.  This  smniech  diould  not 
exclude  work  on  the  larger  and  aore  coaplex 
prograas  at  a  reasonable  level  so  that  the 
full  benefits  of  this  MI  technology  can  be 
realised  in  the  future. 

One  of  the  fundnaontal  liaitations  of  MI  for 
aerospace  electronics  systeas,  as  defined  by 
aost  of  the  speakers  at  this  syaposiua,  is 
the  need  for  real  tiae  eabedded  hardware. 
Before  iapleaentations  can  take  place, 
considerable  progress  needs  to  be 
accoaplished  in  the  developaent  and 
availability  of  airborne  architectures  and 
processors  that  provide  real  tine  deration. 
In  addition,  another  liaitation  of  MI  for 
aerospace  electronics  systea  is  in  the  area 
of  verification  and  validation  of  MI 
solutions.  Vithout  good  aethods  of  doii« 
verification  and  validations,  it  is 
difficult  to  assess  the  naturity  and 
benefits  of  the  technology  and  the 
developed  systeas  will  not  gain  the 
acceptance  necessary  for  najor  systen 
iapleaentation.  Therefore,  it  is 
recoanended  that  an  increasing  share  of 


funds  for  HI  applications  for  aerospace 
electronic  systeas  be  spent  on  the 
(kvelopaent  of  reel  tine  eabedded  hardware 
and  in  the  verification  and  validation 
areas. 

General  Bouchard  nade  interesting  coanents 
about  the  acceptance  of  MI  by  pilots  that 
should  be  considered  by  MI  planners  and 
developers.  In  the  process  of  trying  to 
sell  systeas,  he  has  found  that  aost 
ailitary  pilots  are  not  ready  to  accept 
claias  that  pilots  need  additional  aid  for 
flying  their  aircraft  or  achieving  aission 
objectives.  Pilots  will  not  acc^t  systeas 
which  renove  control  or  aake  decisions 
pertalnijpg  to  critical  flight  or  aission 
paraneters.  Future  systeas  should  be  sold, 
therefore,  on  the  basis  of  their  support  to 
the  pilot  vith  little  attention  given  to 
the  MI  included. 

Many  MI  technologies  were  discussed  at  this 
iua;  however,  no  single  approach  has 
a  capability  of  solving,  in  an 

Stiaua  way,  all  of  the  problea  areas 
scussed.  Therefore,  for  applications  of 
the  future,  it  is  recoanended  that  hybrids 
consisting  of  aixes  of  MI  technologies  be 
used  since  they  offer  the  best  solution  to 
aai^  aerospace  electronics  systen  problens. 
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by 

Philippe  O.  Bouchard 

Director 

Center  for  Artificial  Intelligence  Applications 
31SS  Research  Blvd,  Suite  200 
Dayton,  OH  45420-4066 
United  States 


PreUminary  Remarks 

Thank  you  for  the  kind  introduction,  and  thank  you  to  our  host  nation,  Portugal,  for  the  excellent  conference  accommodations. 
Since  submitting  my  remarks  for  clearance,  a  war  has  been  fought  and  major  United  States  Air  Force  reorganizations  have 
resulted  in  name  changes  for  many  of  the  R&D  organizations  represented  here  today. 

Therefore.  I  am  going  to  depart  slightly  from  the  speech  written  last  year,  which  has  been  overcome  by  many  events. 

Moreover,  I  trust  my  former  compatriots  at  the  United  States  Air  Force's  newly  named  Rome  Laboratory,  and  those  at  the 
newly  named  Wright  Laboratory  will  excuse  my  language  if  I  occasionally  lapse  into  terminology  which  signals  out  either 
avionics  or  C^I.  There  is  no  intention  of  enhancing  the  importance  of  one  versus  the  other... both  are  equally  important 
electronic  system  technologies . . .  developed  in  the  United  States  Air  Force  by  separate  organizations. 

Also,  please  excuse  my  use  of  the  term  Artificial  Intelligence  and  its  abbreviation  Al,  the  term  commonly  used  in  the  United 
States.  I  will  have  more  to  say  about  this  unfortunate  wording  later. 

IntroductkMi 

It  is  opportune  that  AGARD  should  be  addressing  the  topic  “Machine  Intelligence  for  Aerospace  Electronic  Systems"  during  a 
time  of  United  States  defense  spending  cuts  and  economic  recession.  The  United  States  defense  market  will,  for  the  next  few 
years,  best  be  characterized  by  a  curtailment  of  major  new  program  .starts.  The  few  new  systems  which  survive  the  cuts  will 
include  major  advances  in  electronics  integration  and  new  technologies,  such  as  Artificial  Intelligence.  The  Advanced  Tactical 
Fighter  (ATF)  immediately  comes  to  mind,  wherein  its  avioiucs  functional  integration  architecture  coordinates  sensor  fusion, 
synthesizes  cockpit  displays,  monitors  systems'  states,  and  provides  decision  aids.  However  new  systems  such  as  the  ATF  will  be 
the  exception  during  the  decade  of  the  1990s. 

Upgrades  of  existing  aerospace  systems  will  most  likely  be  the  norm,  and  avionics  and  C'l  upgrades  may  be  the  method  most 
employed  for  improving  total  system  performance  because  of  high  operational  payback.  Since  defense  avionics  technology  has 
often  been  the  source  of  advances  in  commercial  aircraft,  and  orders  for  commercial  jet  airliners  are  at  a  record  high  in  the 
United  States,  the  requirement  for  innovative  avionics  techm^ogy  should  remain  strong  despite  tight  budgets.  Althoug^i  United 
States  research  and  development  outlays  will  slow  in  the  early  1990s,  many  companies  have  already  stated  they  will  increase 
R&D  spending  in  electronics,  communications,  and  sensor  technologies. 

During  my  experience  as  Director  for  the  Center  for  Artificial  Intelligence  Applications  (CAIA),  I  have  observed  that  the 
largest  percentage  of  successfully  implemented  knowledge-based  systems  occur  in  commeric^  triplications  to  improve 
decision  making,  productivity,  product  quality,  and  diagnostics.  The  higher  risk,  higher  pay-ofT  intelligent  systems  applications 
have  been  the  domain  of  the  military.  In  fact,  I  have  observed  a  propensity  for  the  United  States  Defense  Department  to  invest  its 
hugest  percentage  of  AI  dollars  in  highly  visible  weapon  systems  applications  versus  the  acquisition  management  techniques 
winch  are  used  to  procure  these  same  weapon  systems.  Nevertheless,  as  the  AI  technology  for  these  higher  risk  military  system 
applications  mature,  commercial  spinoffs  should  be  plentiful.  Thus,  the  market  for  intelligent  electronics  should  remain  strong, 
and  that  is  why  this  conference  on  “Machine  Intelligence  for  Aerospace  Electronic  Sysiems”  is  timely. 

This  paper  briefly  describes  one  of  the  initiatives  taken  by  the  United  States  Air  Force  to  ensure  continued  growth  in  the 
application  of  AI  to  pertinent  problems,  many  in  electronics.  Also  discussed  are  likely  applications  for  future  knowledge-based 
systems  based  on  the  Persian  Gulf  War  experience. 

Tha  Center  far  ArtMcial  IntfBgrnes  Appicatiani 

The  Center  for  Artificial  Intelligence  Applications  (CAIA)  began  its  operations  in  October,  1987.  The  United  States  Air  Force 
at  Wright  Patterson  AFB  in  Ohio,  established  the  CAIA  through  a  $  10  Million  contract.  Its  mission  is  to  adapt  AI  technologies 
for  Air  Force  applications  and  to  expand  the  Dayton,  Ohio,  area  AI  talent  base  through  education  and  training.  The  Center  is 
managed  and  ftiaded  by  the  Aeronautical  Systems  Division.  AI  Technology  Office,  located  at  Wright  Patterson  AFB,  Ohio. 

The  CAIA  consists  of  a  small  staff  and  Al  researchers  from  one  commercial  company  and  seven  Ohio  universities.  This 
consortium  consists  of  Central  State  University,  The  University  of  Dayton,  Case  Western  Reserve  University,  The  University  of 
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Cincinnati,  The  Ohio  State  University,  Sinclair  Community  College,  Wright  State  University  and  Teknowledge  Federal 
Systems.  The  CAIA  staff’s  function  is  mainly  administrative,  although  some  are  involved  in  AI  training  and  prototyping  of 
expert  systems  in  the  Center’s  well-equipped  prototyping  facility.  However,  the  goal  is  to  have  the  majority  of  the  prototyping 
and  applied  research  accomplished  by  the  university  and  commercial  subcontractors  at  their  local  facilities. 

The  Center’s  mission  is  to  satisfy  United  States  Air  Force  requirements;  therefore  work  is  focused  on  AI  applications  rather 
than  basic  research.  Five  major  services  are  provided.  Application  Screenings  are  the  initial  risk/value  assessment  of  a  problem 
which  might  lend  itself  to  an  AI  solution.  Typically  a  panel  of  six  to  ten  consortium  members  (engineers,  scientists,  and 
knowledge  engineers)  interview  an  expert  for  some  two  to  three  hours  to  assess  AI  and  systems  engineering  risks  and  value  to 
the  user.  Those  applications  which  survive  the  initial  screening  are  recommended  for  the  next  step,  AI  Application  Assessments 
which  are  similar  in  format  to  Screenings.  Again,  a  panel  of  consortium  members  interview  an  expert,  this  time  for  some  two  or 
three  days  to  reaffirm  the  screening’s  risk  assessment  and  to  gather  sufficient  information  to  write  a  prototyping  or  applied 
research  plan. 

If  the  application  lends  itself  to  a  knowledge-based  technology  solution,  the  next  step  in  the  series  of  services  is  Rapid 
Prototyping  of  an  Expert  System.  Depending  on  the  complexity  of  the  problem,  this  could  take  six  to  nine  months.  The  result  is  a 
proof-of-concept  system  with  which  the  user  can  decide  whether  to  proceed  to  a  fully  fielded  system. 

If  the  assessment  indicates  high  risks,  but  also  indicates  high  value  to  the  user,  the  Center  typically  will  start  what  is  termed  an 
Applied  Research  and  Development  (R&D)  project  to  reduce  risks  before  starting  a  prototyping  effort.  All  of  the  Center’s  Neural 
Network  R&D  falls  in  this  category. 

The  last  service  provided  by  the  Center  is  AI  Training  to  raise  the  AI  literacy  both  in  the  Air  Force  and  the  local  civilian  sector. 
Short  courses  are  tailored  for  various  levels  of  the  Aeronautical  Systems  Division  11,000  person  work  force.  For  instance,  a 
three-hour  AI  overview  is  taught  for  executives  and  managers,  while  a  four-day  course  on  fundamentals,  a  five-day  hands  on 
course  in  expert  system  development,  and  a  two-day  hands  on  neural  network  workshop  are  attended  by  practicing  scientists, 
engineers,  computer  professionals  and  first-level  supervisors. 

In  summary,  the  five  services  offered  by  the  Center  are  Applications  Screenings.  Applications  Assessments,  Rapid  Prototyping, 
Applied  Research  St  Development,  and  Training. 

The  Center’s  work  generally  fidls  in  the  following  application  areas  of  primary  interest  to  the  Air  Force: 

—  Manufacturing  Technology 

—  Data  Management 

—  Program  Management 

—  Design  Assistance 

—  Diagnostics 

The  first  two  areas.  Manufacturing  Technology,  and  Data  Management,  have  been  determined,  through  a  survey,  to  be  of 
primary  interest  to  the  Dayton  area  industry.  As  the  Center  expands  its  services  to  .serve  the  private  sector,  these  application 
areas  are  emphasized. 

During  the  first  six  months  of  the  Center’s  existence,  seventy  applications  were  screened  and  approximately  half  were 
recommended  for  assessment  or  applied  R&D  in  a  prioritized  order.  Currently,  the  Center  is  working  on  fourteen  projects, 
several  of  which  are  avionics  related. 

Examples  of  some  of  the  avionics  work  currently  being  conducted  are  as  follows; 

Polynomial  Neural  Networks  for  Airborne  Applications 

This  is  an  applied  R&D  project  to  determine  the  feasibility  of  using  neural  networks  in  a  missile  evasion  scenario.  Researchers 
at  Wright  State  University  have  determined  that  a  polynomial  neural  network  can  out-perfoim,  in  speed  and  accuracy,  the 
conventional  look-up  table  technique  in  permitting  a  fighter  aircraft  to  evade  hostile  air  to  air  missiles.  An  additional  finding 
associated  with  this  work  is  that  large  look-up  tables,  when  needed  can  be  constructed  more  efficiently  by  using  a  neural 
network  approach. 

AmtMtutted  Development  t^Tesi  Program  Sets 

This  is  an  applied  R&D  project  to  compare  and  merge  the  strengths  of  two  different  knowledge-based  diagnostic  systems  for 
avionics.  The  (Mio  State  University  and  Central  State  University  are  investigating  the  feasibility  of  closely  integrating  compiled 
knowledge  and  deep  causal  knowledge  based  approaches  to  achieve  a  fast,  accurate,  robust  technique  for  diagnosing  avionics 
malfunctiom. 

Nemul  Networks  for  Processing  Inertial  Navigation  Unit  Data 

This  multiple  phase  project  conducted  by  the  University  of  Dayton  assessed  neural  network  simulations  for  maintaining  the 
pointing  and  tracking  accuracy  of  an  optical  device  detection  system  whose  performance  was  limited  by  insufficient  Inertial 
Navigation  Umt  (INU)  data.  Neund  network  simulations  were  et^uated  using  F- 16  fli^t  test  data  that  sampled  INU  outputs  at 
higher-than-stan^rd  rates.  Results  indicated  that  neural  network  simulations  could  predict  INU  data  at  the  required  rates  and 
accuracy.  Follow-on  work  will  address  the  development  of  neural  network  software  simulations  that  adaptively  smooth  INU 
outputs.  Dr  Stephen  Gustafson  will  describe  in  more  detail  this  project  in  his  presentation. 
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Other  avionics  related  projects  which  are  being  contemplated  include  the  design  of  a  knowledge-based  architecture  for  an 
autonomous  electrical  spacecraft  on-board  power  system,  automatic  target  recognition  using  hierarchical  neural  system,  and 
neural  networks  in  conjunction  with  an  analytic  model  to  form  an  air  to  air  radar  tai;get  identification  system. 

There  are  many  other  on-going  and  prospective  projects  in  areas  such  as  manufacturing,  program  management,  and  design 
assistance.  Each  year  new  applications  are  screened  and  assessed  to  assure  a  continuing  supply  of  relevant  high  priority 
projects. 

The  Center  has  been  successful  in  achieving  its  mission  in  that  expert  systems  and  neural  networks  have  been  applied  to  a 
variety  of  Air  Force  applications,  and  the  Dayton,  Ohio,  At  talent  base  has  certainly  been  expanded.  Over  400  people  have 
attended  the  many  short  courses  offered  by  the  Center  and  numerous  graduate  students  have  participated  on  the  prototyping 
and  applied  R&  D  projects. 

Lessons  Learned 

I  would  like  to  give  you  my  observations,  call  them  lessons  learned  if  you  will,  concerning  the  use  of  AI  in  aerospace  electronic 
systems.  I  would  also  like  to  postulate  some  lessons  learned  from  the  recent  war  in  the  Persian  Gulf  region  where  AI  was  used 
for  the  first  time  in  a  combat  situation. 

You’ll  note  from  my  background  that  I  am  an  aeronautical  engineer  by  education  and  a  technology  generalist  by  practice.  AI  is 
not  my  expertise.  I  suspect  one  of  the  major  reasons  I  was  selected  for  my  current  position  was  to  ensure  the  work  accomplished 
by  our  AI  Center  remains  focused  on  useful  Air  Force  applications.  My  people  often  refer  to  me  as  the  AI  Center’s  “resident 
skeptic”,  which  gives  me  the  feeling  that  I  must  be  doing  something  right. 

And  certainly  having  spent  over  30  years  in  the  United  States  Air  Force,  one  of  which  was  flying  combat  missions  in  the 
Vietnam  War,  I  have  formed  opinions  about  our  recent  experience  in  the  Persian  Gulf,  especially  as  it  relates  to  high-tech 
weaponry. 

Given  that  background,  let  me  make  a  few  observations  about  AI  and  its  future  potential  in  military  aerospace  electronics. 

The  senior  leadership  of  the  United  States  Air  Force  has  been  quoted  in  various  publications  vrith  lessons  learned  from  the  Gulf 
War.  For  instance,  the  Secretary  of  the  United  States  Air  Force  has  taken  the  post-war  position  that  we  must  maintain  our 
technological  edge,  despite  budget  cuts.  Pertinent  to  this  conference’s  agenda,  he  has  signaled  out  special  needs  such  as 
weapons  guidance  in  bad  weather,  advanced  electronic  warfare  techniques  to  disrupt  enemy  C^,  rapid  and  accurate  bomb 
damage  assessments,  and  mobile  missile  detection.  The  allied  force  air  component  commander,  Lt  General  Homer  wants  a 
faster  preparation  for  the  daily  air  tasking  order,  which  at  the  peak  of  the  war,  amounted  to  an  avert^e  of  3,000  sorties  per  day. 
Lt  General  Foraell,  the  Air  Force  Systems  Command  Electronics  Systems  Division  commander  states  that  future  high  priority 
programs  will  address  better  fusion  of  data . . .  and  the  presentation  of  that  information  in  an  easy-to-use  form. 

Certainly  these  are  important  future  systems  needs,  many  of  which  could  incorporate  AI  technology. 

Let  me  add  a  few  to  this  list.  One  of  the  most  important,  non-perishable  lessons  from  the  Gulf  War  is  the  importance  of  excellent 
training.  Future  conflicts  more  than  likely  will  not  afford  us  five  months  of  force  build  up  and  in  theater  training.  I  believe  there  is 
a  need  for  intelligent  training  techniques  to  obviate  the  high  operations  and  maintenance  cost  of  training  in  aircraft.  Although 
today’s  state-of-the-art  simulators  are  good,  I  agree  they  cannot  replace  flying  time  for  effective  training.  These  training  systems 
must  be  improved  with  ‘intelligence”,  to  be  better  alternatives  to  increasingly  scarce  flying  time. 

With  the  cutting  back  of  aircraft  and  flying  time,  we  may  have  to  reconcile  additional  use  of  unmanned  flying  vehicles, 
particularly  in  reconnaissance.  There  is  much  potential  for  AI  in  this  application,  principally  in  adaptive  modification  of  vehicle 
performance.  Capabilities  needed  are  multi-sensor  fusion,  automated  sensor  management,  dynamic  mission  replanning,  and 
automatic  target  recognition. 

In  future  conflicts,  we  cannot  rely  on  the  large  deployment  of  civilian  contractors  to  support  our  high-tech 
weaponry... needlessly  putting  these  civilians  in  harm’s  way.  Tlierefore,  we  must  increasingly  automate  our  diagnostics  and 
technical  manuals,  embedding  knowledge-based  systems  where  it  makes  sense.  We  must  do  the  latter  without  creating  a  need  to 
deploy  knowledge  engineers  to  support  such  systems.  In  other  words.  AI  systems  of  the  future,  especially  deployable  diagnostic 
systems,  must  allow  the  user  to  modify  or  maintain  the  knowledge  base. 

And  finally,  let  me  next  address  a  pet  peeve  of  mine . . .  system  user  friendliness.  For  those  of  you  who  have  not  yet  read  the  29 
April  issue  of  Business  Week,  I  commend  it  to  you.  The  artificial  intelligence  tedmology  we  are  discussing  at  this  conference, 
dmpite  increasingly  successful  use  in  commercial  and  military  operations,  still  has  two  strikes  against  it.  First  of  all,  its  name. 
Artificial  Intelligence,  evokes  skepticism  in  any  potential  user.  I  compliment  you  for  using  the  term  Machiim  Intdligence,  but 
you  are  fighting  a  dtfficuU  battle  in  trying  to  get  ^  term  adopted  in  the  United  States.  I  trM  unsuccessfully  to  inject  that  same 
term  in  the  vocabulary  of  the  Air  Force  Systems  Command  in  1983—1984.  The  term  Artificial  Intelligence  is  firt^y  embedded 
in  the  United  States  commercial  vocabulary.  The  second  obstacle  which  must  be  overcortM  is  the  felse  expectations  associated 
with  this  technology.  Of  the  many  technologies  I  have  worked  with  during  my  career,  this  one  has  been  liyped”  the  most  The 
user  community  hu  been  stung  with  high  development  costs  and  false  expectations,  although  that  is  changing  with  respect  to 
expert  systems.  Given  those  obstacles,  the  last  thing  a  developer  would  want  to  do  is  to  encumber  an  AI  system  with  a  user 
unfriendly  interfece.  Americans  are  starting  to  rebel  against  the  devil  of  user  unfriendly  designs.  The  Business  Week  article 
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states  that  consumers  are  being  made  to  feel  like  technological  illiterates... and  they  don’t  like  it.  Simplicity... not 
complexity. . .  is  the  true  mark  of  any  well  designed  product.  My  A1  Center  learned  its  lesson  in  this  area  when  we  prototyped  an 
expert  system  which  advises  engineering  project  managers  on  which  of  over  ISOO  possible  data  items  should  be  requested  on 
research  and  development  procurement  actions.  Initial  user  reaction  was  best  characterized  as  “moderate  apathy”  because  we 
emphasized  the  AI  portion,  which  amounted  to  less  than  10%  of  the  total  programming  effort.  It  was  only  after  we  added  a 
government  form  printing  capability  to  this  prototype  that  the  system  was  enthusiastically  embraced.  I  suspect  that  some  of  the 
more  successful  AJ  systems  deployed  to  the  Persian  Gulf  War  will  prove  to  be  heavy  on  user  friendliness  and  light  on  AI  content. 

Summary  and  Conchision 

In  summary,  the  United  States  Air  Force's  Center  for  AI  Applications  in  Dayton,  Ohio,  is  applying  machine  intelligence  to  a 
variety  of  military  aerospace  electronics  problems,  and  simultaneously  is  exp^ulding  the  Dayton  Area  AI  talent  pool,  from 
whidi  Wright  Patterson  Air  Force  Base  can  recruit.  The  recent  war  in  the  Persian  Gulf  has  highlighted  many  potential 
applications  of  AI,  and  when  lessons-leamed  are  published  on  those  AI  systems  which  were  deployed,  I  suspect  system  user- 
friendliness  will  play  as  important  a  role  as  knowledge-based  sophistication.  Despite  United  States  Defense  research  and 
development  budget  cutbacks,  I  believe  investment  will  remain  robust  for  intelligent  aerospace  electronics  systems,  not  only  for 
its  potential  in  preserving  the  free  world's  defense  aerospace  technological  edge,  but  also  for  its  spinoff  potential  in  commercial 
aerospace  applications. 

Again,  thank  you  for  your  invitation  to  join  you  at  this  conference.  I  am  looking  forward  to  hearing  your  presentations. 


COMPONENT  PART  NOTICE 
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1.  SUHMARY 

The  development  of  communications 
networking  technologies  that  increase 
the  survivability  of  services 
provided  to  military  users  has  been 
an  important  goal  in  Air  Force 
programs  over  the  past  several  years. 
This  enhanced  survivability  is  a 
result  of  work  that  has  focused  on 
two  areas:  the  development  of  more 
robust  communication  equipment,  and 
the  development  of  a  management 
system  that  coordinates  the  use  of 
that  equipment.  This  paper  will 
discuss  the  role  of  machine 
intelligence  in  the  design  of  such  a 
network  management  system.  Emphasis 
will  be  placed  on  the  intelligent 
Q  network  management  decision  making 
.(X.  capabilities  that  are  required  in  a 
Tniijtary  environment,  and  the  design 
tra^offs  which  must  be  made  in 
developing  a  system  that  can  optimize 
the  system-wide  use  of  resources 
without  the  need  for  human  ^ 
intervent  iof^  ^ — 


A  current,>tT ^orce  research  effort 
titled  "The  Integrated  Comninl cations 
Network  Management  System  ,  or  INS, 
will  be  used  as  a  case  study  for  an 
overview  of  the  critical  Issues  that 
comprise  this  paper. 

2t-H?T  QF  SYHML? 

ICN  -  Integrated  Communications 
Network 


IMS  -  ICN  Management  System 


LAN  -  Local  Area  Network 

LOS  -  Line  Of  Site 

PBX  -  Private  Branch  Exchange 

3.  BACKGROUND 

The  military  networking  environment 
imposes  a  number  of  constraints  upon 
the  way  in  which  specific  machine 
intelligent  technologies  can  be 
implemented.  These  constraints 
include  short  response  times, 
processing  power  limitations,  limited 
transmission  bandwidth,  and  the 
potential  loss  and  destruction  of 
assets.  To  better  understand  the 
context  In  which  machine  intelligence 
is  applied  to  the  design  of  a 
survivable  network  management  system, 
it  will  be  helpful  to  discuss  the 
communications  requirements  which 
characterize  the  Air  Force  networking 
environment. 

3.1  Requirements 

The  Air  Force  Is  designing  its  future 
communications  systems  to  meet  the 
following  six  fundamental 
requirements: 

1)  Interoperability  -  Primarily 
through  International  standards 

2)  Integrated  Services  -  From  a 
single  control  Interface 

3)  Security  -  User  and  access 
authentication,  and  secure  services 


ISON  -  Integrated  Services  Digital 
Network 


4)  Survivability  -  Intelligent 
networking  algorithms 


1-2 


5)  Flexibility  -  In  defining  and 
providing  services 

6)  Capacity  -  Load  balancing  of 
resources 

Each  of  the  above  requirements  has 
been  identified  as  a  deficiency  of 
past  or  present  networks.  Rome 
Laboratory  has  initiated  the  IMS 
program  to  develop  a  management 
system  architecture  which  addresses 
these  deficiencies.  Machine 
intelligence  technologies  have  been 
targeted  to  the  survivability 
requirement  for  the  IMS. 

3.2  The  ICH 

The  combination  of  all  the 
transmission  resources 
(communications  media,  switches, 
multiplexers,  networks,  etc.),  and 
all  non- IMS  management  systems  that 
can  be  monitored  and/or  controlled  by 
the  IMS  shall  be  referred  to  as  the 
Integrated  Communications  Network,  or 
ICN.  Some  of  the  resources  and 
management  systems  within  the  ICN  may 
not  be  under  the  control  of  the  IMS, 
in  which  case  the  INS  must  treat  that 
resource  as  a  ”b1ack  box"  from  which 
it  can  request  a  connection.  A 
simple  conceptual  illustration  of  the 
ICN  is  provided  in  Figure  1.  The  ICN 


concept  includes  a  distributed  set  of 
nodes  that  host  network  management 
processes  for  the  ICN.  These  network 
management  processes  form  the  ICN 
Management  System,  or  IMS.  Note  that 
Figure  1  reflects  the  distributed 
nature  of  the  IMS.  Machine 
intelligence  technologies,  in  the 
form  of  network  management  decision 
making  algorithms,  form  the  core  of 
the  IMS.  The  remainder  of  this  paper 
will  discuss  in  detail  the  nature  of 
these  technologies. 

4.0  THE  IMS 

The  performance  objective  of  the  IMS 
is  to  provide  the  communications 
network  management  functions  that 
optimize  the  use  of  all  surviving 
transmission  resources  on  a  system- 
wide  or  "global"  level,  while 
providing  users  with  an  increased 
survivability  and  availability  of 
services  during  all  phases  of  an 
attack.  The  IMS  thus  provides  the 
reactive  capabilities  for  a 
communications  system  to  "fight  back" 
against  enemy  attacks. 

4.1  IMS  Machine  Intel! ioent 
Capabilities 

Machine  intelligence  technology  in 
the  IMS  will  enable  the  automatic 
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operation  and  control  of  Its  three 
major  functions;  service 
provisioning,  resource  provisioning, 
and  service  fault  resolution.  The 
IMS  employs  Intelligent  algorithms  to 
Implement  these  functions,  which  will 
be  discussed  In  detail  In  later 
sections.  These  Intelligent 
management  algorithms  must  take 
courses  of  action  to  adapt  the 
provisioning  status  of  the  INS 
subsystems  to  dynamically  meet  the 
communications  needs  of  Its  users, 
particularly  In  a  hostile  environment 
where  Its  resources  are  subject  to 
damage  and  destruction.  The  human 
administrator/network  manager  Is  only 
required  for  Initial  network 
configuration,  establishment  of 
administrative  domain,  and  Input  of 
the  "master  communications  plan", 
which  keeps  track  of  subscribers  and 
their  accounts  and  the  administrative 
status  of  resources  In  that  domain. 
Keep  In  mind  the  fact  that  the  INS  Is 
a  distributed  management/control 
architecture,  as  depicted  In  Figure 
2.  Dispersed  INS  nodes  must 
communicate  with  each  other  and  other 
management  entitles,  possibly  across 
multiple  administrative  domains,  to 
develop  a  concurrent  knowledge  of  the 
"global  state"  of  the  network. 
Information  fusion  Is  therefore  a  key 
requirement  for  each  of  the  three  IMS 


functions  at  the  system  level,  with  a 
goal  of  making  an  "Intelligent” 
management  decision  that  Is  based 
upon  pieces  of  Information  that  are 
sometimes  Incomplete  or  Inaccurate. 

4.1.1  Service  Provisioning 

The  IMS  automates  the  process  of 
satisfying  the  service  requests  of 
communications  users  In  a  three  stage 
service  provisioning  process  (See 
Figure  3).  Two  of  these  stages, 
service  mapping  and  service 
assignment,  rely  upon  machine 
Intelligence  In  their  design  and  will 
be  discussed  In  more  detail.  The 
service  provisioning  function  of  the 
INS  Is  to  optimally  map  all 
communications  service  requests  to 
the  available  transmission  resources. 
An  INS  "service"  Is  defined  In  a 
manner  similar  to  the  ISON  method  for 
characterizing  a  service.  The  IMS 
defines  a  service  In  terms  of  Its 
associated  access.  Information 
transfer,  and  general  attributes  (See 
Table  I). 

4. 1.1.1  Service  Happing 

The  first  stage  of  service 
provisioning  Is  service  mapping, 
where  user  service  requests  must 
first  be  translated  Into  specific 
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Figure  3  -  THE  SERVICE  PROVISIONING  PROCESS 


Table  I  •  IMS  SERVICE  DEFINITION 


ACCESS  ATTRIBUTES 


User  Descriptors  (r\ame,  password,  priviledges,  priority) 


Service  Establishment  Mode  (demand,  reserved,  permanent) 


Symmetry  (simplex,  half  duplex,  duplex) 


Protocol  (TCP/IP,  TP-4,  X.25,  etc.) 


INFORMATION  TRANSFER  ATTRIBUTES 


Information  Transfer  Rate  (bit  rate  or  throughput) 


Information  Transfer  Type  (voice,  data,  video) 


Configuration  (point-to-point,  multipoint,  broadcast) 


GENERAL  ATTRIBUTES 


Quality  Of  Service  (survivability,  availability,  reliability) 


Performance  (delay,  error  rate) 


Security  Level  (Unclassified,  confidential,  secret,  top  seaet) 
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Table  II  -  RESOURCE  REQUIREMENTS 


Service  ID 

Source  User  Name 

Destination  User  Name(s) 

Priority 

Type 

Protocol 

Status 

Start  Time 

End  Time 

Survivability  Requirements 
(reconstitution,  AJ.  LPI) 

Symmetry 

Maximum  Delay 

Security  Level 

Data  Rate 

Maximum  AHowable  Error  Rate 

resource  requirements  which  are 
needed  to  support  that  service. 

Table  II  Illustrates  the  type  of 
Information  that  constitutes  a 
resource  requirement.  The  attributes 
that  characterize  a  service  dictate 
which  transmission  resources  are 
acceptable.  It  Is  the  task  of  the 
service  mapping  phase  to  Insure  that 
there  Is  no  ambiguity  of  the  nature 
of  the  resources  that  are  required  to 
satisfy  a  given  request.  These 
resource  requirements  are  then  passed 
to  the  service  assignment  phase. 

4.1. 1.2  Service  Aii1qi»ent 

The  next  stage  of  service 
provisioning  Is  service  assignment, 
where  every  resource  requirement  has 
to  be  matched  with  a  suitable  subset 


of  the  resources  that  are  actually 
available  at  that  time.  The  types  of 
resources  that  can  be  allocated  are 
connections,  links,  ports  and 
equipment.  Connections  In  the  ICN 
are  defined  as  end-to-end 
communications  pipelines.  Links  are 
the  point-to-point  segments  through 
which  connections  are  routed.  Ports 
are  the  access  points  to  connections. 
Equipment  covers  the  physical 
communication  boxes  (transmit  and 
receive)  that  are  allocated  to 
connections,  such  as  modems  and 
multiplexers. 

The  service  assignment  process  must 
allocate  the  connectlon(s)  that  are 
required  to  satisfy  a  service 
request.  In  the  case  where  no 
existing  connection  can  satisfy  a 
service  requirement,  the  service 
assignment  process  must  check 
existing  links  to  see  If  resources 
can  be  combined  to  create  a  new 
connection  that  can  support  that 
service.  This  decision  Is  based  on 
topology  Information  which  Identifies 
the  links  and  equipment  that  can  be 
used  to  provide  a  service.  This 
resource  topology  Information  Is 
provided  by  the  resource  provisioning 
process,  which  will  be  discussed  In 
the  next  section. 

Another  application  for  Intelligent 
algorithms  In  the  service  assignment 
process  Is  when  there  Is  more  than 
one  path  In  the  IHS  that  can  satisfy 
a  service  request.  In  this  case,  a 
procedure  Is  Invoked  that  will  select 
the  "closest  to  optimal"  set  of 
resources  .  This  selection  Is  based 
upon  the  chosen  performance  metrics 
for  the  IHS,  from  a  local  versus 
system-wide  perspective  (e.g..  Do  we 
minimize  local  congestion,  or  perform 
global  flow  control,  or  something  In- 
between?).  The  choice  of  resources 
for  service  assignment  Is  therefore 
determined  using  the  relative  weights 
of  decision  criteria  such  as; 
maximize  system-wide  throughput  and 
connectivity,  minimize  blocking, 
minimize  congestion  In  regional 
sectors  and  over  scarce  resources  at 
the  system  level,  and  perform  access 
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control  on  unauthorized  users.  Note 
that  there  May  be  conflicts  at  the 
system  level  which  the  INS  must 
resolve  when  trying  to  optimize  each 
of  the  above  parameters.  The 
mapping  of  specific  system  goals  to 
network  metrics  and  the  assignment  of 
relative  weights  to  each  metric  In  a 
flexible  and  dynamic  manner  In 
response  to  constantly  changing  user 
needs  and  operational  conditions  Is  a 
key  function  of  the  INS.  With  this 
capability,  the  INS  helps  to  reduce 
the  degree  to  which  users  and  system 
administrators  are  required  to  be  In 
the  loop  to  execute  the  allocation  of 
available  resources  to  user  service 
requests. 

4.1.2  Resource  Provisioning 

The  resource  provisioning  function  of 
the  INS  Involves  the  determination  of 
the  status  and  configuration  of  the 
transmission  assets.  After  the 
resources  are  made  available  by  the 
resource  provisioning  process,  the 
service  provisioning  process  controls 
the  utilization  of  those  resources  by 
making  decisions  In  response  to  each 
service  request.  The  assignments 
made  by  the  service  provisioning 
process  affect  resource  utilization 
and  traffic  load  balance,  which 
demonstrates  the  strong 
Interdependency  between  service  and 
resource  provisioning. 

The  resource  provisioning  process 
performs  two  major  functions,  which 
are  the  determination  of  resource 
availability  and  the  management  of 
link  and  equipment  configuration  to 
support  the  establishment  of  links 
and  connections  for  service 
provisioning. 

4. 1.2.1  Nonitor  System  Topology 

The  INS  system  topology  Is  comprised 
of  the  collection  of  available  INS 
resources,  their  current 
configuration,  and  Information 
regardino  their  end-to^end  service 
availability.  The  system  topology 
InformatiM  Is  supplied  to  the 
service  provisioning  process  to 


facilitate  the  optimal  matching  of 
services  to  resources.  The  topology 
Information  can  be  represented  by  a 
directed  multigraph,  where  INS  nodes 
are  vertices  and  communication  links 
are  edges.  The  following  paragraph 
discusses  the  means  by  which  the 
resource  provisioning  process  can  use 
this  topology  Information  to  assist 
in  the  decision  making  processes 
associated  with  topology  management. 

4tit2t2-  HMMd-BwQyrcg 
CgnflQurrtlOT 

The  resource  connectivity  and  status 
Information  gathered  by  system 
topology  algorithms  Is  used  to  manage 
the  configuration  of  resources  In 
support  of  the  resource  provisioning 
function  of  the  INS.  The  INS  thus 
automates  the  process  of 
reconfiguring  and  reallocating 
surviving  assets  In  the  cases  where 
existing  services  have  failed,  so 
that  the  users  are  shielded  from  the 
actions  that  are  required  to  perform 
this  task.  For  an  added  level  of 
protection  from  potential  loss  of 
service,  the  INS  also  monitors  cut¬ 
set  and  congestion  problems  and 
recommends  possible  solutions.  A 
cut-set  represents  a  split  In  the 
connectivity  of  a  network  that 
creates  separate  Islands  of 
connectivity  among  the  remaining 
assets. 

4,1.3  Pprfgnwnct  AmIysU  ftr  FavU 

Resolution 

Performance  analysis  Is  an  Integral 
function  of  the  INS  which  assists  the 
service  and  resource  provisioning 
processes,  especially  when  assets  are 
degraded  and  lost  In  the  course  of 
providing  required  services.  Data 
concerning  link  and  equipment 
failures  Is  used  to  perform  trend 
analysis  and  localization  of  fault 
scenarios,  and  current  or  predicted 
performance  problems.  These 
performance  problems  Include  the 
Identification  of  cut-sets  and 
congestion  areas  discussed  In 
4.1. 2.2. 


1-7 


In  executing  performance  analysis, 
performance  data  and  resource  status 
Information  are  compared  with 
expected  values  so  that  service 
faults  can  be  Identified.  Cut-set 
algorithms  are  run  to  detect  current 
and  potential  future  cut-sets. 

Traffic  analysis  algorithms  are  also 
run,  so  that  transmission  congestion 
points  can  be  located.  Finally,  all 
of  this  analysis  data  Is  used  to 
manipulate  the  service  provisioning 
process  so  that  services  can  be 
reassigned  to  correct  or  avoid  the 
problems  that  were  Identified. 

5.0  CONCLUSION 

In  summary,  an  INS  node  provides  a 
communication  user  with  a  survivable. 
Integrated  control  Interface  to  the 
services  of  various  networks  and 
transmission  resources,  while 
screening  that  user  from  the 
Idlosyncracles  of  accessing  the 
Individual  systems  and  from  the 
reconstitution  actions  that  the  INS 
Initiates  to  restore  failed  services. 
The  INS  can  thus  be  considered  an 
Intelligent  "manager  of  managers”, 
which  provides  dispersed  system-wide 
network  management  decision  making 
capabilities  to  automate  the 
processes  of  service  and  resource 
provisioning  and  network 
reconstitution. 

The  role  of  machine  Intelligence 
technologies  In  the  development  of 
the  survivable  communications  network 
management  system  discussed  In  this 
paper  Is  centered  on  the  need  to 
reduce  the  degree  to  which  users  and 
system  a(fai1n1strators  are  required  to 
be  In  the  loop  to  allocate  available 
global  resources  to  user  service 
requirements,  throughout  all  phases 
of  an  attack. 

This  paper  has  used  the  INS  program 
as  a  case  study  to  outline  some  of 
the  potential  applications  for 
machine  intelligence  In  the  design  of 
survivable  network  management 
systems.  Uork  Is  still  continuing  In 
the  Identification  of  areas  In 
network  management  where  machine 


Intelligent  functions  can  be 
Integrated  to  enhance  the 
survivability  of  the  systems  being 
developed. 
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Discussion 

1.  Prof.  A.N.  Ince,  Tkukey 

You  have  addressed  in  your  talk  only  the  requirements  that 
users  may  have  for  a  survivable  communication  network. 
Can  you  please  comment  on  what  measures  you  are 
considering  which  can  benefit  from  machine  intelligence 
techniques  to  meet  the  needs  of  the  users  for  reliable/ 
continuous/timely  service? 

Author 

The  discussion  of  requirements  at  the  beginning  and  end  of 
this  presentation  was  made  to  emphasize  what  requirements 
formed  the  basis  of  the  IMS  program.  The  incorporation  of 
machine  intelligence  techniques  such  as  expert  systems  for 
trend  analysis  and  foult  resolution;  the  use  of  information 
fusion  concepts  to  collect  incomplete  pieces  of  management 
information  and  make  an  intelligent  decision  as  to  the 
current  “^obal”  state  of  the  network;  are  good  examples  of 
how  MI  is  being  applied  to  this  effort  The  published  paper 
gives  a  better  description  of  applications. 

2.  Dr  G.H.Hunt,  United  Kingdom 

1  am  interested  to  hear  more  about  the  security  aspects  of  the 
Network  Management  System.  Are  there  different  levels  of 
security  protection  in  the  netwoik  links  and  different 
security  levels  in  the  message  contents,  and  does  this 
complicate  the  network  management? 

Author. 

The  IMS  handles  security  in  two  ways.  First,  from  a  user 
standpoint,  only  authorize]  users  are  allowed  to  access  the 
IMS  at  the  appropriate  level  of  clearance.  The  IMS  then 
guarantees  the  security  of  that  service  by  sdecting  only  the 
links  which  are  capable  of  meeting  the  security  requirements 
of  that  service.  Very  importantly,  the  IMS  does  not  itself 
handle  the  user  data  or  message  contents  (other  titan 
headers),  but  rather  it  communicates  with  the  transmission 
fabric  (switches,  multiplexets,  etc.)  and  establishes  the  links 
that  are  capable  of  supporting  the  security  requirements  of 
that  data.  Internally,  Ae  Management  Information  Base 
(MIB)  contents  of  the  IMS  must  be  a  trusted  system  becai  e 
this  is  where  the  information  regarding  Mieie  the  network 
resources  are,  that  can  support  that  service. 
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SUMMARY 


This  paper  discusses  the  Advanced  Artificial 
Intelligence  Technology  Testbed  (AAITT)  being 
sponsored  by  Rome  Laboratory.  The  purpose  of 
this  testbed  Is  to  provide  a  powerful 
environment  for  Integrating  dissimilar 
software  systems  Including  expert  systems, 
conventional  software,  databases,  and 
simulations  distributed  over  a  network.  In 
addition,  this  testbed  will  provide 
measurement  and  analysis  tools  for  evaluating 
the  results  of  the  various  user-supplied 
software  components.^ 


^ectl 


Section  2  of  this  paper  discusses  the  need  for 
operational  software  support  systems  to 
cooperate  with  one  another  and  for  these 
systems  to  be  thoroughly  tested.  Section  3 
covers  previous  attespts  at  getting  decision 
aids  to  work  together.  Section  4  discusses 
the  AAITT  In  more  detail.  Including  Its  goals 
and  high  level  design.*^ 


The  AAITT  will  be  based  on  the  ABE  (A  Better 
Environment)  module-oriented  system  and  on  the 
Cronus  distributed  confuting  environment. 

This  will  allow  the  various  components  to 
communicate  transparently  over  a  heterogeneous 
network.  Generic  database  and  simulation 
capabilities  will  be  provided  to  support  the 
development.  Integration,  and  testing  of  new 
software  components. 

2.  PREFACE 


An  Intelligent  command  and  control  (C2) 
decision  aid  often  begins  its  life  In  a 
"sterile'  laboratory  environment.  Each 
decision  aid  Is  developed  to  solve  a 
relatively  narrow  problem  within  the  overall 
C2  declslon-maklng/  management  problem.  To 


provide  the  user  guidance,  this  aid  has 
sources  of  data  and  knowledge  stored  In  local 
format (s) ,  a  problem  solving  methodology  which 
uses  the  knowledge  to  reason  over  the  data, 
and  usually  the  ability  to  Interact  with  the 
user.  Testing  may  be  performed  by  presenting 
the  aid  with  predefined  scenarios  and 
comparing  the  results  to  some  standard.  While 
this  approach  may  be  adequate  In  the 
laboratory  setting,  what  happens  when  this 
tool  Is  brought  Into  the  operational  realm? 
That  Is,  when  It  Is  brought  Into  an 
environment  where  Information  may  be  stored  In 
several  databases  and  where  multiple  decision 
aids  and/or  conventional  programs  are  working 
at  various  portions  of  the  overall  problem. 
Finally,  how  reliable  will  this  system  be, 
having  been  developed  in  Isolation  thousands 
of  miles  from  the  battlefield?  To  answer  some 
of  these  questions,  the  Rome  Laboratory  has 
embarked  on  the  development  of  the  AAITT,  a 
distributed  environment  that  will  support  the 
testing  of  and  cooperation  among  multiple 
decision  aids.  The  testbed  is  being  developed 
by  a  team  of  contractors  lead  by  General 
Electric  Aerospace  Advanced  Technology 
Laboratories. 

Before  going  further,  several  terms  need  to  be 
defined.  A  component  Is  a  stand-alone 
software  program  designed  to  solve  part  of  an 
overall  problem  (see  Figure  1).  User-supol led 
components  (USCs)  refer  to  those  components 
which  the  application  developer  supplies  and 
wants  connected  to  the  testbed.  A  module  is  a 
component  with  some  type  of  software  "wrapper* 
that  allows  it  to  communicate  with  other 
modules.  An  AAITT  application  Is  a  collection 
of  modules  configured  to  work  Interactively  to 
solve  an  overall  problem. 


Figure  1. 


Testbed  terminology 


ZU _ CQOBflratlQn  bstween  DsclalQii  Alda 

Many  decision  aids  have  been  developed  In 
various  military  planning  domains.  These 
Include  mission  schedulers  (e.g.,  KRS  [1], 
TEMPIAR  [2],  AMPS  (31),  route  planners  (e.g., 
RPDH  [4],  HERO  (SJ),  and  a  variety  of 
databases  and  simulations,  see  Figure  2. 

These  systems  are  usually  developed 
Independently  with  no  plan  for  Interacting 


with  other  systems.  However,  in  "real*  usage 
these  systems  will  need  to  work  together  to 
solve  much  broader  planning  problems  and  need 
to  access  data  located  In  remote  databases. 
Researchers  have  often  eitphaslzed  the 
Investigation  of  new  reasoning  techniques 
applied  to  simplistic  problems  over  these 
Interoperability  Issues. 
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Figure  2.  Exan^les  of  related  software  applications  developed  on  dissimilar  systems 


2^ _ Tflatina/VflilfliiaUQfl/^lldation 

Software  systems  are  usually  developed  by 
first  trying  to  understand  the  needs  of  the 
end  user  and  then  mapping  these  needs  to 
requirements/specifications.  This  Is  the 
"what  the  software  should  do'  portion.  The 


second  phase  Is  developing  the  system  by 
mapping  the  requirements/specifications  to  the 
design/  Implementation.  This  is  the  "how  the 
software  will  do  It'  portion.  These  mapping 
processes,  shown  In  Figure  3,  are  usually 
Informal  and  are  thus  sources  of  error. 


System 

Requirements/ 

Specifications 


Design/ 

Implementation 


Figure  3.  Software  Development  Process 


As  systems  are  developed,  the  need  exists  for 
rhtm  to  be  tested  before  entering  Into  the 
operational  domain.  This  Is  necessary  In 
order  to  quantify  and  qualify  the  errors 
Introduced  In  the  development  process. 
Exhaustive  testing  Is  impractical  for  software 
systems  with  even  moderate  complexity. 
Theoretical  proof  testing  Is  likewise 


difficult  and  must  be  rechecked  for  even  minor 
modifications.  Still,  there  needs  to  be  some 
level  of  confidence  that  the  software  works  as 
advertised  and  as  expected.  This  testing 
includes  verification  and  validation,  shown  In 
Figure  4. 


2-3 


Verification  Is  concerned  with  the  correctness 
of  the  algorithms  or  reasoning  process  of  the 
software.  For  exang>le,  "does  a  sorting 
algorithm  work  for  negative  numbers?"  or  "does 
the  mission  planner  select  the  best  available 
aircraft?"  A  system  that  provides  a  commander 
with  the  wrong  answer  could  lead  to  disaster. 
Another  Inportant  part  of  verification  Is  the 
need  for  decision  aids  to  work  on  large  size 
problems.  Often,  promising  techniques  do  not 
scale-up  appropriately.  For  Instance  the 
mission  planner  may  work  fine  for  planning  X 
missions  on  a  given  cong>uter,  but  may  require 
too  much  time  or  actually  crash  the  machine 
when  attenq>tlng  to  plan  2X  missions.  Part  of 
verification  should  be  the  determination  of 
what  size  problems  can  be  handled  and  how 
gracefully  the  system  degrades. 

Validation  Is  concerned  with  showing  that  the 
software  satisfies  the  needs  of  the  user.  For 
example,  "does  the  user  really  require  the 
absolute  best  flight  path  through  the 
threats?"  or  "did  the  user  want  to  consider 
other  types  of  displays  for  the  requested 
Information?"  In  support  of  this,  there  has 
been  more  and  more  Interest  In  the  use  of 
rapid  prototyping  to  support  Iterative 
development.  Often  operational  users  have 
only  a  limited  understanding  of  their  own 
needs.  When  asked  to  describe  their 
requirements,  they  must  rely  on  past  systems 
as  points  of  reference.  While  this  Is  a 
start.  It  does  not  provide  the  user  with  an 
understanding  of  what  could  be.  With  rapid 
prototyping,  a  user  gets  to  "play"  with  the 
system  early  In  the  development  process.  By 
actually  sitting  down  and  trying  different 
features,  a  user  can  begin  to  describe  more 
accurately  his  or  her  actual  needs.  This  Is 
an  Iterative  process  as  the  user  discovers 
what  Is  really  needed  In  a  system.  This  then 
becomes  part  of  the  validation  process. 

X _ PREFACE 

While  there  have  been  many  attempts  at 
decision  aid  (and  conventional  software) 
cooperation,  the  underlying  models  used  have 
often  been  a  variation  on  two  main  cooperation 
techniques.  These  techniques  are  based  on 
either  a  decentralized  or  centralized  theory 
of  control  and  are  characterized  by  the  amount 
of  knowledge  each  decision  aid  has  about  the 
other  decision  aids  versus  the  degree  of 
central  control  present  In  the  system. 

The  decentralized  approach  provides  a  more 
efficient  form  of  distributed  processing, 
however  Important  characteristics  such  as 
global  data  sharing  and  reconfigurability  are 


not  easily  obtained.  The  centralized  approach 
provides  for  the  sharing  of  global  data 
through  a  common  data  source.  While  this  aids 
In  system  reconfigurability  and  extendlblllty, 
resulting  bottlenecks  can  become  a  problem. 

Architectures  that  can  be  considered 
decentralized  Include  the  hardwired  and 
broadcast  configurations  while  centralized 
approaches  Include  the  blackboard.  Information 
broker,  and  meta-level  controller 
architectures  [6].  The  following  section 
looks  at  these  architectures  and  presents  some 
exanples  of  previous  work  that  have  been  done 
In  the  cooperating  expert  systems  domain. 
Section  4  describes  the  software  controlled 
architecture  (soft  architecture)  being  used  In 
the  Advanced  Artificial  Intelligence 
Technology  Testbed  (AAITT) .  This  approach 
will  allow  developers  to  graphically  define 
the  architecture  most  appropriate  for  their 
application. 

XJ _ Decentralized  Technloues 

A  decentralized  system  architecture  can  l>e 
viewed  as  one  where  the  Information  flow  and 
data  exchange  does  not  travel  through  a  common 
agent  (or  number  of  agents) .  The  most  popular 
examples  of  this  type  of  Interaction  include 
the  hardwired  and  broadcast  architectures. 

3.1.1 _ Hardwired  Architecture 

A  "hardwired*  architecture  consists  of  a 
number  of  decision  aids  cooperating  through 
direct  calls  to  one  another.  Because  of  this, 
each  aid  on  the  network  Is  required  to  know  a 
lot  about  the  other  decision  aids  It  will 
Interact  with.  Typically  Interaction  among 
the  aids  is  through  direct  function  calls 
which  are  embedded  Into  each  aid  at 
development  time.  Since  these  function  calls 
are  "hardwired*  Into  the  aids,  the 
architecture  is  fixed  and  difficult  to  modify. 
If  a  decision  aid  Is  not  available  on  the 
network  Its  task  will  not  be  completed 
regardless  of  whether  another  aid  can  handle 
the  job.  Sharing  common  data  can  also  present 
problems  In  this  type  of  architecture.  Issues 
such  as  storage  management  and  updates  can  be 
very  entailed  In  large  hardwired  systems  where 
common  Information  Is  needed  by  many  of  the 
decision  aids.  Figure  5  shows  an  example  of  a 
simple  tiardwized  configuration  wlioxe  dMlslon 
aid  1  provides  direct  Input  to  decision  aid  2 
and  decision  aid  3.  These  two  aids  then 
interact  in  working  towards  a  solution. 
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Figure  5.  Hardwired  Architecture 


3-1-1-1 _ ftLIiIES 

The  MITRE  ALLIES  [7]  project  attempted  to  get 
two  existing  expert  systems  to  cooperate  In 
constructing  a  military  plan  (Figure  ()  using 
a  "hardwired*  approach.  The  system  Included 
tnree  components:  a  tactical  Intelligence  aid, 
ANALYST,  which  reconstructed  enemy  force 
dispositions  on  a  map,  an  AI  planning  system, 
OPLANNER,  which  handled  a  large  portion  of  the 
command  and  staff  responsibilities,  and  an 
object-oriented  simulation.  Battlefield 
Environment  Model  (BEM) ,  which  modeled  and 
simulated  the  OPLANNER  results. 

Because  the  OPLANNER  and  ANALYST  were  written 
In  the  same  language  and  ran  on  the  same 
machine  It  was  relatively  easy  to. get  these 
systems  to  cooperate.  Network  communication 
was  not  necessary  since  the  two  systems  were 
hosted  on  the  same  machine.  Because 
communication  was  established  through 
extensive  changes  to  both  the  OPLANNER  and 
ANALYST  software,  eventually  the  ANALYST 
became  more  or  less  a  subprocess  of  the 
OPLANNER.  Communication  to  BEM  was  obtained 
through  simple  file  transfer  among  machines. 
Overall,  the  above  techniques  did  produce 
efficient  data  sharing  and  a  minimum  of 
communication,  however  extensive  knowledge  of 
the  other  systems  had  to  be  ’hardwired*  Into 
each  system.  Nhlle  this  guarantees  a  system 
will  have  the  data  It  requires  to  accon^llsh 
Its  task,  problems  could  arise  when  the  system 
becomes  very  complex  or  more  decision  aids 
must  be  added  to  the  architecture  (6). 


Figure  6.  ALLIES 


3.X.1.2 _ Cooperatlno  Expert  avstems  ir-OPE<S> 

The  (XIPES  project  ((]  studied  the  problem  of 
coordinating  cooperation  between  existing. 
Independently  developed  system.  After  doing 
an  analysis  of  past  research.  Advanced 
Decision  Systems  proposed  a  software  solution 
which  would  coMblne  aspects  of  other 
approaches  to  provide  an  architecture  for  the 
Integration  of  three  existing  decision  aids. 
Minimal  changes  on  existing  decision  aids 


would  be  required.  The  decision  aids  to  be 
used  Included  the  Automated  C3CM  Battle 
Management  Decision  Aid  (ACBMDA) ,  the  Tactical 
Expert  Mission  Planner  (TEMPLAR) ,  and  the 
FORCES  simulation  [6]. 

The  main  concept  behind  the  COPES  design  was 
to  provide  each  decision  aid  with  Its  own 
customized,  knowledge-based  ’wrapper.*  This 
wrapper  would  serve  as  an  Interface  to  the 
other  decision  aids  and  would  possess 
knowledge  about  its  own  Inputs,  outputs, 
goals,  and  other  requirements.  The  initial 
plan  was  to  also  Include  knowledge  about  other 
specific  decision  aids  and  how  to  cooperate 
with  them  using  these  wrappers.  Some  meta¬ 
level  knowledge  would  also  be  used  for 
cooperation  of  decision  aids  that  were  not 
customized  explicitly.  In  the  long  term, 
specific  decision  aid  knowledge  was  to  be 
extracted  from  the  wrappers  and  Inserted  Into 
a  shared  COPES  knowledge  base.  The  wrapper 
concept  underlying  COPES  provides  a  more 
modular  design  and  less  modification  of 
existing  decision  aids  than  the  ’hardwired* 
design  of  ALLIES.  Still,  Information  about 
other  decision  aids  must  be  coded  Into  each 
new  decision  aid  wrapper.  Since  each  wrapper 
Is  ’customized*,  a  new  one  must  be  developed 
for  each  aid,  regardless  of  whether  It's  of 
the  same  type  (e.g.,  planner)  as  a  previous 
aid  In  the  system.  Since  each  wrapper  has  a 
lot  of  information  about  other  decision  aids. 
It  may  be  difficult  to  add  or  replace  decision 
aids.  The  long  term  design  plans  of  using 
meta-level  knowledge  and  a  COPES  knowledge 
base  could  help  ease  this  problem.  Figure  7 
provides  an  overview  of  the  COPES  wrapper 
concept. 
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Figure  7.  COPES  Architecture 


3..!. 2 - Broadcast  Architect  lire 

The  broadcast  architecture  differs  from  the 
hardwired  model  in  the  way  data  Is 
represented  and  decision  aid  communication 
takes  place.  In  the  broadcast  model  all 
decision  aids  must  understand  a  coitmon  data 
representation.  The  aids  must  distinguish 
what  type  of  Information  requests  they  can 
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handle  since  all  decision  aid  output  Is 
broadcast  over  the  entire  network  of  systems. 
Any  decision  aid  that  can  service  a  particular 
request  will  do  so  In  this  type  of 
architecture.  Figure  8  shows  a  typical 
broadcast  architecture  where  three  decision 
aids  Interact  through  broadcasted  message 
traffic. 
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Figure  8.  Broadcast  Architecture 


2^ _ Centralized  Technlgnaa 

A  centralized  architecture  is  based  on  the 
concept  of  some  type  of  controlling  or  common 
agent  through  which  all  Information  and  data 
exchange  takes  place.  Centralized  techniques 
Include  the  blackboard,  Information  broker, 
and  meta-level  controller  architectures. 

3.2.1 _ Blackboard  Architecture 


3-2.2 _ Information  Broker  Architecture 

The  Idea  behind  the  information  broker  [6J 
concept  Is  to  have  various  'broker*  agents 
responsible  for  specific  Information  exchange. 
Each  broker  Is  responsible  for  a  specific  type 
of  message  request  or  exchange  that  a  decision 
aid  may  make.  The  decision  aids  Interact 
directly  with  the  brokers  that  handle  their 
Input  and  output  needs  and  do  not  require 
Information  about  the  other  decision  aids  on 
the  network.  They  do  however  need  to  have 
knowledge  about  the  brokers  that  can  handle 
their  requests.  Representation  translations 
must  also  be  done  between  the  brokers  and  the 
various  decision  aids.  Figure  10  shows  a 
basic  information  broker  configuration  where 
all  the  decision  aids  have  message  interaction 
with  two  'brokers.' 


Figure  10.  Information  Broker 


The  blackboard  architecture  (81  Is  based  on 
the  Idea  of  a  common  workplace  (or  blackboard) 
where  a  problem  can  be  Incrementally  solved. 
Each  decision  aid  Is  responsible  for  a 
specific  portion  of  an  overall  problem  and  Is 
allowed  access  to  the  'blackboard*  when  the 
appropriate  partial  solution  (or  data)  Is  made 
available  by  the  other  agents.  Some  sort  of 
controlling  mechanism  Is  needed  to  monitor  the 
blackboard  and  determine  which  decision  aid 
should  execute  next.  In  this  type  of 
configuration,  decision  aids  do  not  need  to 
know  Information  about  the  other  knowledge 
sources  Involved  In  the  process  (see  Figure 
9). 


Figure  9.  Standard  Blacitboard  Architecture 


A  variation  on  this  architecture  would  be  to 
broadcast  decision  aid  requests  to  all  of  the 
brokers,  having  the  appropriate  broker  handle 
each  message  (see  Figure  11) .  This  would 
replace  the  *)iardwlred*  connections  from 
decision  aid  to  broker,  becoming  somewhat 
similar  to  the  broadcast  architecture 
described  In  Section  3.1.2.  The  difference 
would  be  the  existence  of  a  (or  possible  many) 
centralized  controllers  rather  than  direct 
contact  between  the  decision  aids. 


Figure  11.  Broadcast  Information  Broker 
Architecture 


- Meta-Level  Controller  Arehlt-aetiira 

The  meta-level  controller  architecture  (Figure 
12)  is  based  on  controller  objects  which  are 
responsible  for  message  traffic  among  the 
decision  aids  In  the  system.  A  controller 


2-6 


object  (sometimes  called  a  wrapper)  Is  usually 
responsible  for  one  decision  aid,  but 
sometimes  handles  several  of  them.  This 
differs  from  the  brolcer  paradigm  In  that  a 
controller  would  handle  a  specific  type  of 
decision  aid  whereas  brolcers  handle  specific 
types  of  Information,  regardless  of  what  aid 
It  Is  generated  from.  The  long  term  plans  for 


the  COPES  project  described  In  Section  3.1.5 
was  to  provide  meta-level  controllers  to  each 
decision  aid  In  the  system.  In  the  COPES 
project  these  controllers  (wrappers)  would 
each  be  responsible  for  one  decision  aid  only 
and  would  possess  (cnowledge  concerning 
cooperation  rules  among  each  other. 


3.2.4  TAC-2:  A  Testbed  for  Integrating 
Decision  Aids 

TAC-2  [9]  was  designed  as  a  demonstration  of 
the  concept  of  Integrating  Al-based  Command 
and  Control  decision  aids.  The  work  was  based 
on  TAC-1  (10),  an  effort  to  develop  a 
framework  for  knowledge-based  system 
cooperation,  and  leveraged  off  of  the  lessons 
learned  In  the  ALLIES  project  described  above. 
The  framework  developed  through  the  TAC-1  work 
was  called  the  Knowledge-Based  Battle 
Management  Shell  (KB-BATMAN  shell)  and  was 
demonstrated  In  the  TAC-2  effort  through  Its 
use  In  the  Integration  of  three  knowledge- 
based  decision  aids.  The  Integrated  aids 
Included  an  Air  Force  mission  planner,  an 
Intelligence  analyst,  and  a  simulator.  The 
KB-BATMAN  shell  provided  a  common  database  and 
"Intelligent*  message  router  object  through 
which  the  decision  aids  could  repetitively 
cycle  through  the  C2  process  of  intelligence 
analysis,  planning,  and  simulated  execution. 
The  Figure  13  below  shows  the  KB-BATMAN 
architecture.  All  Information  and  data 
exchange  Is  passed  through  a  common  database 
(blackboard)  with  a  router  component  serving 
as  the  Intelligence  behind  database  access  and 
control . 


Figure  13.  KB  BATMAN  Architecture 


XJ _ CaimnBn  Problems 

In  some  form,  the  efforts  described  above  all 
contain  concepts  and  Ideas  from  the  different 
architectures  mentioned  throughout  Section  3. 
For  each  project,  the  architecture  was  chosen 
to  provide  the  most  efficient  and  economical 
solution  to  the  specific  problem  at  hand. 

While  all  have  their  advantages,  there  are 
also  disadvantages  Inherent  In  each  design. 
Problems  such  as  extensibility,  modularity, 
scalability,  and  bottlenecks  are  areas  where 
each  of  these  models,  at  some  point,  begins  to 
fail.  In  addition,  the  problems  of  testing 
and  evaluation  of  decision  aids  (discussed  In 
Section  2.2)  are  not  addressed  by  these 
architectures.  The  following  section 
describes  work  being  done  to  develop  a  "soft 
architecture"  which  will  allow  an  application 
to  be  configured  and  reconfigured  until  a 
desired  architecture  Is  found.  The  system 
will  also  provide  metrics  for  evaluation  of 
the  various  aids,  assisting  the  user  In  areas 
such  as  design,  analysis,  and  Integration  as 
well  as  providing  a  flexible  medium  for 
cooperation. 
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L. _ AAIII 

The  goal  of  the  Rome  Laboratory  Advanced  AI 
Technology  Testbed  Is  to  develop  a  decision 
ald/conventlonal  software  Integration 
environment  which  will  allow  the  user  to: 

1.  Easily  configure  various  application 
suites  by  providing  tools  to  add  or 
remove  user-supplied  components,  or  to 
modify  the  communication  paths  of  the 
various  problem  solving  modules, 

2.  Provide  generic  database  and  simulation 
modules  that  can  be  tailored  to  the  needs 
of  the  current  application, 

3.  Observe  and  trace  these  modules'  actions 
and  Interactions, 

4.  Select,  gather,  and  review  metrics  and 
statistics  on  run-time  performance,  and 


5.  Rapidly  change  the  flavor  of  the 

interactions  among  the  suite's  components 
based  upon  the  results  of  previous  runs. 

lU - Soft  Architecture 

The  components  of  the  AAITT  are  shown  In 
Figure  14.  They  consist  of  the  testbed 
manager  (later  described  as  the  HCM 
Workstation),  a  database,  a  simulator,  and 
various  USCs.  The  grayed  sections  represent 
Interface  software.  A  software  controlled 
architecture  (soft  architecture)  has  been 
chosen  for  the  AAITT.  A  soft  architecture  is 
one  that  can  be  graphically  configured  and 
modified  by  a  testbed  manager,  while 
minimizing  the  recoding  of  the  Interface 
software  by  hand.  An  example  configuration  Is 
shown  In  Figure  15.  To  try  a  different 
communication  architecture  (e.g.,  a  blaclcboard 
approach  Instead  of  data-flow) ,  the  user  would 
make  the  necessary  changes  using  the  graphical 
Interface  provided  by  the  testbed  manager. 


Figure  1  .  Network  View  of  an  AAITT  Application 


Figure  15.  An  Experimental  Architecture  of  an  AAITT  Application 


To  support  t)te  soft  architecture  envisioned  by 
the  AAITT,  three  major  sub-systems  are  being 
developed.  These  are  the  Distributed 


Processing  Substrate  (DPS) ,  the  Module 
Framework,  and  the  Modeling,  Control,  and 
Monitoring  (MCM)  Workstation. 
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A. 1.1 _ Distributed  Processing  Substrate 

The  DPS  will  allow  dissimilar  software  systems 
(e.g.,  databases,  simulations,  expert-systems, 
and  conventional  software)  running  on 
heterogeneous  hardware  platforms  (e.g.,  VAX, 
SUN,  and  Symbolics)  to  Interact  with  one 
another.  An  Important  feature  of  the  DPS  is 
that  Is  will  translate  data  representations 
between  the  various  hardware  systems  and 
programming  languages.  Several  candidates 
were  considered  by  the  contractor  team  for 
providing  the  foundation  of  the  testbed  and 
are  shown  In  Table  1 .  The  criteria  for 
selection  was: 

1.  Runs  on  Sun  3/4  and  Symbolics  36xx. 

2.  Runs  on  Vaxs  running  VMS  and  ULTRIX. 

3.  Runs  with  applications  written  In 

C/C++  and  Common  Lisp. 

4.  Runs  with  applications  written  In 

Ada. 

5.  Provides  Interface  specification  and 

stub  code  generators. 


6.  Provides  application  building  tools. 

7.  Stable,  mature  product. 

The  resulting  evaluation  of  each  candidate  is 
shown  in  Table  2.  Based  upon  this  analysis, 
the  Cronus  distributed  confuting  environment 

[11]  was  selected.  Cronus  provides 
heterogeneous  host  support  for  distributed 
application  development.  It  gives  the  user  an 
object-oriented  view  of  resources  on  a 
network.  In  addition  to  this  object-oriented 
view  provided  by  Cronus,  the  DPS  will  use  ABE 

[12] ,  providing  a  module-oriented  programming 
capability.  This  will  allow  the  structuring 
of  a  distributed  testbed  application  at  a 
higher  level  than  Cronus.  The  ABE  environment 
supports  modules  which  are  Independent 
entitles  that  communicate  data  and  control 
among  themselves  through  very  well-defined 
Interfaces.  The  goal  Is  to  use  the  higher- 
level,  computational  and  architectural  model 
provided  by  ABE  with  the  lower-level, 
distributed  system  environment  support 
provided  by  Cronus. 


Table  1.  Candidate  Testbed  Message  Passing  Environments 


Product 

Developer 

Alpha 

Carnegie  Mellon  Univ. 

Cronus 

BBNCorp. 

ISIS/Meta 

Cornell  University 

Mach 

Carnegie  Mellon  Univ. 

MetaCourler 

Symbiotics,  Inc. 

StarO/S 

ADS  Coro. 

113] 


Table  2.  Candidate  Environment  Evaluation 


Product 

Sun3/4 

Symbolcs 

VIBX 

\M5 

UMrix 

<vc++ 

Common 

Usp 

Adh 

Inisriaoe 

IniertBoe  spec 
aslubCode 
Qeneralors 

Appticaton 

Building 

Tods 

stability 

Alpha 

None 

Poor 

Cronus 

Yes 

YES 

YES 

future 

YES 

Excellent 

Excellent 

ISIS/Meta 

Good 

Excellent 

Mach 

YES 

YES 

Good 

Excellent 

MetaCourier 

YES 

« 

YES 

YES 

Good 

Fair 

Star  0/S 

YES 

YES 

None 

Excellent 

*  unknown  [13] 


— Modula  fraMWorlt 

The  Module  Framework  will  allow  the  user  to 
easily  embed  a  new  component  In  the  AAITT. 

This  framework  is  used  to  create  Conponent 
Interface  Managers  (CIMs) .  A  CIM  Is  a  wrapper 
that  provides  the  Interface  between  the 
distributed  testbed  and  each  component.  The 


Module  Framework  will  facilitate  the  creation 
of  the  CIM  by  guiding  the  user  through  the 
creation  process  and  by  providing  a  library  of 
generic  CIMs.  The  CIM  Is  very  similar  to  the 
wrapper  concept  used  In  COPES.  One  difference 
is  that  the  AAITT  provides  a  seml-automated 
generator  for  easily  creating  and  modifying 
CIMs,  whereas  the  COPES  wrappers  are  coded  by 
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hand.  Another  difference  Is  that  CIMs  allow 
the  testbed  to  control  module  loading. 
Initialization,  resetting,  etc. 

There  are  several  types  of  communication  that 
will  occur  at  a  given  CIM.  These  types 
Include  simple  reception  and  transmission  of 
data,  and  may  Include  more  conpllcated 
transmissions  which  then  wait  for  a  response. 
When  transmitting,  the  CIM  must  know  which 
module  to  send  the  message  to.  The  name  of 
the  destination  module  will  be  set  when  the 
user  completes  the  modeling  phase  at  the  MCM 
Workstation.  The  recipient  can  easily  be 
changed  by  making  the  appropriate  changes  at 
the  workstation.  (Note:  the  actual  location 
on  the  network  of  the  receiving  module  will  be 
maintained,  transparently  to  the  user,  by  the 
DPS.)  CIM  to  CIM  message  types  Include  ASCII 
text.  Integer,  real,  and  database  query 
response . 

4.1.3 _ Mfldfiling.  Control,  and  Monitoring 

WorKautlaa 

The  MCM  workstation  will  provide  a  central 
user  console  for  building  and  configuring 
applications,  and  for  the  display  and  analysis 
of  performance  metrics  gathered  during 
application  runs.  The  modeling  functions  will 
allow  a  user  to  specify  graphically  how  the 
modules  are  to  Interact  with  one  another 
during  execution.  This  will  define  the 
architecture  of  the  application.  The  control 
functions  will  allow  the  user  to  load. 
Initialize,  execute,  and  reset  the  con^onents 
distributed  over  the  testbed's  network.  Break 
point  capabilities  will  aid  In  the  debugging 
process.  The  monitoring  functions  will  allow 
the  user  to  specify  measurements,  monitors, 
and  Instrumentation.  Measurements  refer  to 
the  quantifiable  features  that  help  the  user 
understand  system  performance.  Monitors  are 
the  procedures  through  which  measurements  are 
captured.  Instrumentation  allows  the  user  to 
process  the  resulting  measurements  and  present 
them  In  an  appropriate  manner.  The  monitoring 
capabilities  of  the  MCM  Workstation  will  be 
very  Important  In  testing  out  the  USCs  and  set 
the  AAITT  apart  from  testbeds  that  simply  try 
to  connect  existing  systems. 

4-2  Tasting 

As  stated  In  Section  2.2,  It  Is  Important  to 
understand  the  strengths  and  weaknesses  of  the 
USCs  before  providing  them  to  operational 
units.  These  weaknesses  may  Include  actual 
errors,  problem  size  limitations,  excessive 
run  times.  Incompatibilities,  and  so  on.  The 
AAITT  will  have  features  to  address  both  the 
verification  and  validation  problems  addressed 
In  Section  2.2 

idJLU _ VtniflcatlQfl  -  la  tha  aaftwara  dalng 

Uia.  JgtL  xifliit? 

The  end  users  must  have  some  confidence  that 
the  USCs  will  work  as  advertised.  To  verify 
the  results  of  the  USCs,  the  AAITT  will 
provide  metrics  for  evaluation  and  heuristics. 

4.,3LA.3 _ Wauica 

Metrics  will  be  provided  by  the  MCM 
Workstation  as  discussed  In  Section  4.1.3. 
Timing  and  memory  limitations  will  be 
addressed  by  these  metrics.  In  addition. 


bottlenecks  will  be  Identified,  possibly 
Indicating  that  a  new  application  architecture 
should  be  selected  or  that  faster 
computers/networks  should  be  used.  Higher 
level  metrics  will  also  be  addressed,  for 
Instance  the  number  of  mission  routes  planned 
per  minute,  or  the  speed  at  which  the 
simulation  simulates  one  hour  of  time. 

4.2. 1.2  _ Evaluating  a  solution  heurlstlcallv 

The  quality  of  a  solution  cannot  be  determined 
by  the  speed  of  the  Inference  engine  or  the 
number  of  queries  handled  by  the  database  per 
minute.  Quality  can  sometimes  be  assessed  by 
using  some  type  of  heuristic.  To  support 
this,  the  AAITT  will  need  some  type  of  generic 
heuristic  evaluation  module  that  can  be 
tailored  to  evaluate  a  given  class  of  USCs. 

For  Instance,  a  route  planner  heuristic 
evaluation  module  may  take  the  planned  routes 
and  determine  for  each  route  If  the  specified 
aircraft  can  fly  at  the  chosen  altitudes.  If 
the  aircraft  has  enough  range,  given  the 
available  on-board  fuel,  and  whether  the  legs 
of  the  route  are  too  short  (difficult  to 
follow)  or  too  long  (vulnerable  to  enemy 
attack) .  This  evaluation  module  could  be  used 
regardless  of  which  specific  route  planner  was 
being  tested. 

4.2.2  _ Validation  -  Is  the  software  doing  the 

right  1ob? 

The  end  users  need  to  make  sure  the  USCs 
really  address  their  particular  problems.  To 
validate  whether  or  not  the  USCs  are  meeting 
their  needs,  the  testbed  will  provide  rapid 
prototyping  facilities  and  the  benefit  of 
graphical  simulations. 

1.2. 2 U _ gxQtatypIaa  eBYlroiunent 

The  testbed  will  allow  component  developers 
the  ability  to  quickly  demonstrate  their 
systems  in  a  realistic  environment.  By 
providing  both  database  and  simulation 
capabilities,  developers  can  concentrate  on 
software  algorithms  and  user  Interface  Issues, 
Instead  of  developing  sets  of  problems  and 
ways  to  evaluate  results.  This  will  mean  that 
use  users  can  be  brought  In  earlier  In  the 
development  process,  allowing  them  to  direct 
or  redirect  the  developers  before  design 
decisions  are  made.  This  process  will  help 
developers  better  understand  the  users'  needs, 
not  just  the  users'  stated  requirements. 

4. 2. 2. 2  _ gfapLlcal  simulation 

The  simulation  component  will  provide  a 
simulation  language  and  various  tools  for 
developing  graphical  simulations.  This  will 
allow  users  to  monitor  the  execution  of  plans 
developed  by  the  USCs.  The  simulation 
language  Is  designed  to  be  Interactive  so  that 
user  developed  simulations  can  be  stopped, 
queried,  modified,  and  continued  at  any  point. 
This  type  of  Interactive  simulation  should 
help  In  determining  whether  the  USC  developer 
has  really  addressed  the  user's  needs. 

4 ■ 3  Components 

The  AAITT  will  have  generic  conf>onents  to 
facilitate  the  development  and  testing  of 
USCs.  These  generic  components  have  been  used 
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to  create  demonstration  components  to  plan 
missions  In  the  tactical  air  combat  domain. 

4.3.1  Generic  Components 

Conventional  and  “expert"  software  work  by 
understanding  the  problem  at  hand, 
automatically  or  semi -automatically  attempting 
to  solve  the  problem,  and  then  posting  the 
results  (usually  to  a  screen  or  file) . 
Databases  and  simulations  can  provide  a 
supporting  environment  for  evaluating  these 
types  of  software  systems.  A  database  can  be 
used  to  present  the  (JSCs  with  specific  problem 
scenarios.  Once  the  USCs  finish  processing, 
the  results  of  the  components  can  be  stored  In 
the  database  for  later  evaluation.  Heuristics 
can  be  helpful  In  evaluating  the  quality  of  a 
result,  for  Instance  the  routes  chosen  by  a 
route  planner  could  be  evaluated  on  the 
percentage  of  time  that  allied  aircraft  are 
exposed  to  enemy  air  defenses.  If  a  heuristic 
Is  not  available,  a  simulation  could  be 
helpful,  allowing  a  human  evaluator  to  see  the 
results  of  following  the  recommendations  of  a 
particular  (JSC.  Generic  components  will  be 
provided  to  develop  these  types  of  databases 
and  simulations. 

4. 3. 1.1  _ Database 

The  testbed  will  have  a  generic  database  for 
storing  and  retrieving  Information  needed  by 
the  (JSCs.  Results  of  the  (JSCs  can  be  stored 
In  the  database  for  later  evaluation.  The 
Oracle  relational  database  has  been  chosen  as 
the  testbed's  database  shell.  (Jslng  the  DPS, 
the  database  will  appear  as  a  module  In  the 
testbed  that  can  respond  to  structured  query 
language  (SQL)  statements.  As  additional 
databases  are  created,  they  can  then  be  used 
by  other  (JSCs. 

4. 3. 1.2  _ Simulation 

The  testbed  will  have  a  generic  simulation 
capability  to  show  the  consequences  of 
following  the  results  of  the  other  modules. 

The  ERIC  object-oriented  simulation  language 
has  been  chosen  as  the  testbed's  simulation 
language  [141.  ERIC  Is  based  on  the  Common 
Lisp  Object  System  (CLOS)  and  allows  the 
simulation  developer  to  develop  a  hierarchy  of 
object  classes  with  associated  behaviors  and 
attributes.  ERIC  allows  objects  to  be  created 
dynamically  and  for  the  simulation  to  be 
halted,  modified,  and  continued  without 
reconciling.  The  message  parser  provided  by 
ERIC  allows  for  expressive  message  passing. 
Results  from  the  simulation  can  be  posted  to 
the  database  or  sent  on  to  (JSCs. 

4 >3.2 _ Damonatratlan  CflinBonanta 

Demonstration  components  will  be  used  during 
the  AAITT  demonstrations  to  show  the 
feasibility  of  the  testbed. 

4. 3.2.1  TAC-DH 

The  Tactical  Database  (TAC-OB)  provides  a 
realistic,  though  unclassified,  laydown  of 
tactical  units  and  equipment  In  the  central 
European  theater  [15).  This  database  was 
developed  by  Knowledge  Systems  Corporation 
(KSC)  in  1969  and  reflects  the  MATO  and  Marsaw 
Pact  capabilities  at  that  time.  In  addition 
to  identifying  where  units  are  located,  the 


database  contains  Information  on  Individual 
weapon  systems.  As  new  (JSCs  are  added  to  the 
testbed  with  new  requirements  for  domain 
Information,  TAC-DB  will  be  extended  to 
provide  the  necessary  support. 

TAC-DB  provides  the  “blue-view"  of  the  world 
for  the  (JSCs.  This  means  that  Information  In 
the  database  Is  only  as  accurate  as  blue 
Intelligence  Is.  This  makes  sense  since  (JSCs 
should  not  be  able  to  access  more  Information 
than  the  blue  side  knows.  (Note:  there  may  be 
some  “red-view"  Information  stored  In  the 
database  used  only  by  the  simulator  to  create 
red  units,  etc.,  that  are  currently  unknown  to 
the  blue  side.) 

4. 3.2.2  _ L&CE 

The  Land  Air  Combat  In  ERIC  (LACE)  simulation 
simulates  the  tactical  engagement  of  NATO  and 
Warsaw  Pact  forces  In  the  central  European 
theater  [161.  The  simulation  reads  In 
friendly  and  enemy  unit  information  from  TAC- 
DB,  creates  these  objects,  and  then  executes 
air  tasking  orders  (ATOs)  also  stored  In  the 
database.  Friendly  air  missions  must 
penetrate  through  enemy  air  defenses  In  order 
to  attack  targets.  As  missions  return,  their 
results  are  posted  to  TAC-DB  for  use  by  the 
uses. 

LACE  contains  the  ground  truth  for  the 
scenario.  The  (JSCs  do  not  have  direct  access 
to  this  ground  truth  data,  only  to  the  TAC-DB. 
The  (JSCs  could,  however,  be  used  to  schedule 
LACE  reconnaissance  missions  which  will  post 
their  Intelligence  reports  to  TAC-DB  upon 
completion.  This  Information  then  becomes 
available  to  the  other  modules  of  the  testbed. 

4. 3.2.3  _ D£&l,sloa  Alda 

Two  decision  aids  will  be  Included  as  part  of 
early  demonstrations.  These  Include  the  Air 
Force  Mission  Planning  System  (AMPS)  developed 
by  The  MITRE  Corporation  and  portions  of  the 
Route  Planner  Development  Workstation  (RPDW) 
developed  by  the  Jet  Propulsion  Laboratory. 
AMPS  [3]  was  developed  to  support  the  planning 
and  replanning  of  ATOs.  ATOs  are  the  plans 
used  by  NATO  to  conduct  air  missions.  AMPS 
contains  domain  knowledge  concerning  aircraft 
and  weapon  capabilities,  weapon  system 
availability,  and  scheduling  constraints.  In 
addition  to  planning  these  missions,  AMPS  was 
developed  to  Intelligently  support  replanning, 
the  process  of  fixing  a  plan  which  has 
problems,  without  replanning  the  whole  ATO. 

The  RPDW  [41  was  designed  to  facilitate  the 
development  and  evaluation  of  route  planning 
algorithms.  Our  route  planner  Is  one  of  the 
algorithms  provided  by  the  RPDW.  To  use  this 
planner,  the  user  must  first  develop  a  threat- 
contour  map  based  on  the  location  and  line  of 
sight  of  the  various  air  defense  systems.  The 
planner  then  determines  a  route  through  the 
map  while  attempting  to  minimize  aircraft 
vulnerability.  The  results  generated  by  J(MPS 
and  the  route  planner  will  be  sent  to  TAC-DB 
and  then  on  to  the  simulation.  The  Idea  Is  to 
provide  feedback  to  the  decision  aid 
developers  concerning  their  systems. 


5.0  Conclusion 

C2  decision  aids  and  conventional  programs  are 
being  developed  to  support  operational 
corrananders.  An  environment  Is  needed  to  allow 
these  dissimilar  systems  to  easily  work 
together.  In  addition,  realistic  testing  of 
these  components  Is  required  to  make  sure  they 
perform  as  expected.  The  AAITT  Is  designed  to 
address  these  concerns  by  providing  a  loosely 
coupled,  distributed  support  environment, 
allowing  Independently  developed  aids  to 
cooperate.  The  generic  database  and 
simulation  capabilities  will  allow  for  easy 
development  and  evaluation  of  C2  decision 
support  systems.  If  the  database  is  large 
enough  and  the  simulation  can  provide  updates 
at  fast  enough  rates,  the  testbed  can  present 
the  decision  aids  with  realistic  wartime 
environments.  This  is  the  kind  of 
interoperability  and  evaluation  that  is  needed 
before  fielding  composite  operational  systems. 
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Discussion 


1.  J.Bait,  Umted  States 

Explain  what  you  meant  by  working  the  “transportation 
problem?”  What  is  your  organization  doing  in  this  area? 

Author 

DART,  Resource  planning,  etc.  The  Rome  Laboratory 
Knowledge  Engineering  Branch  (RL/COES,  soon  to  be 
RL/C3CA)  is  working  with  United  States  TRANSCOM  to 
apply  AI  technology  to  the  cargo/transportation  palling 
problem.  To  address  this  problem  we  are  investigating  case 
based,  constraint-based,  and  fuzzy-logic  reasoning,  among 
others.  DART  is  an  early  prototype  to  address  part  of  this 
problem.  It  is  a  somewhat  intelligent  hront  end  to  a  database 
containing  a  planning  scenario.  Since  DART  uses  Cronus 
and  an  Oracle  database,  it  should  be  easy  to  int^rate  into 
the  AATTT. 

2.  Charles  Knieger,  United  States 

Do  system  tests  “prove”  system  compliance  under  all 
conditions? 

Author 

No.  Proof  must  come  from  analysis  of  component  parts  of 
system. 
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HEURISTIC  ROUTE  QPTIMIZATIQM 
A  Model  for  Force  Level  Route  Planning 


Lt  Janet  L.  Barboza 
Rome  Laboratory,  COAA 
Grlffiss  Air  Force  Base,  NY  13441-5700 
USA 


U _ SUMMARY 

A  major  shortcoming  of  tools  and  methods 
currently  employed  for  route  planning  is  that 
they  do  not  incorporate  force-level  factors, 
or,  if  they  do,  the  representation  is 
Inadequate.  Many  Important  factors  necessary 
for  approaching  the  best  possible  route  are 
Ignored.  Heuristic  Route  Optimization,  or 
HERO,  an  exploratory  development  project  of 
the  Advanced  Concepts  Branch  of  Rome 
Laboratory,  Is  a  model  for  automated  route 
generation  for  force-level  mission  planning. 
Object  Oriented  techniques  and  a  dynamic 
threat  representation  allow  detailed  analysis 
of  multiple  planning  variables  In  prod)>clng 
effective,  survlvable  mission  plans^ 


INTRODUCTION 


prodjtcln' 


The  threat  environment  is  the  greatest 
obstacle  to  mission  accomplishment;  the 
likelihood  of  survival  is  diminished  by  enemy 
defenses.  Threat  avoidance  Is  often 
Impossible  due  to  such  basic  constraints  as 
fuel  supply  and  range  limitations.  Thus, 
effective  mission  planning,  which  takes  Into 
account  the  threat  environment  through  which 
missions  will  be  directed,  is  essential  to 
mission  accomplishment. 

Current  planning  methods  plan  single  sortie 
paths  that  fall  to  Incorporate  much  of  the 
complexity  that  affects  the  quality,  and 
therefore  survivability,  of  the  mission  or 
missions  flown.  The  human  planner  most 
likely  will  be  unable  to  effectively  analyze 
many  variables  without  the  aid  of  automated 
tools.  Not  only  Is  he  constrained  by  time 
and  the  limitations  of  his  own  knowledge, 
many  parameters  may  not  even  be  at  his 
disposal  for  evaluation. 

Automation  Increases  the  number  of  variables 
that  can  be  analyzed  for  mission  planning. 

Yet  automated  tools.  Including  those  that  use 
dynamic  prograiranlng  to  minimize  the  sum  of 
the  lethalities  along  a  proposed  path,  do  not 
adequately  represent  the  threat  environment. 
They  are  not  flexible  enough  to  do  so,  and 
therefore  are  limited  as  well. 

Object-oriented  design  and  Implementation 
provides  a  vehicle  to  further  enhance  the 
automation  of  mission  planning  functions.  By 
using  object-oriented  techniques,  the 
parameters  essential  for  optimal  mission 
planning,  such  as  airframe  configuration  and 
the  threat  environment,  can  be  represented  as 
"objects."  The  Interaction  of  objects  allows 
the  program  to  be  flexible  and  dynamic.  The 
HERO  program  demonstrates  the  advantage  of 
using  object-oriented  techniques  In  automated 
route  planning. 


3.  FORCE  T.F.VRT.  APPROACH 

Existing  tools  and  current  methods  for  route 
planning  are  narrow  In  their  scope,  usually 
planning  for  a  single  penetrator  alone  in  a 
static  threat  environment.  In  reality, 
however.  It  Is  very  unlikely  that  a  single 
penetrator  will  fly  over  sterile  airspace. 
Others  will  have  gone  before,  or  will  come 
after.  The  threats  will  not  always  react  In 
exactly  the  same  way,  depending  Instead  on 
conditions  at  a  given  time.  To  bring  the 
flight  of  a  single  penetrator  to  the  reality 
of  the  air  battle  requires  a  deeper  and  more 
expansive  evaluation  of  the  interaction  of 
penetrators  and  threats. 

Ideally,  all  the  parameters  affecting  the 
route  would  be  evaluated  In  mission 
planning.  Type  and  number  of  penetrators, 
connectivity  of  the  threat  network, 
availability  of  countermeasures,  environment 
variables,  speed  and  altitude  are  just  a  few 
of  the  many  planning  variables  necessary  to 
employ  force-level  .tdctlc.5  and  s.trat,eay  to 
produce  a  more  efficient,  more  effective, 
overall  plan,  in  addition  to  creating  plans 
for  individual  sorties.  An  object-oriented 
approach  to  the  representation  of 
penetrators,  threats,  and  the  environment 
allows  detailed  analysis  and  manipulation  of 
such  variables  In  order  to  not  only  produce 
realistic  routes,  but  to  suggest  the  best 
employment  of  tactics  such  as  electronic 
warfare  and  saturation. 


L. _ THREAT  ENVIRONMENT 

Whether  planning  a  single  sortie  or  multiple 
sorties,  a  planning  tool  must  adequately 
represent  the  threat.  Speed,  altitude, 
electronic  warfare,  terrain,  and  on-board 
countermeasures  are  factors  that  can  be  used 
to  lessen  vulnerability  to  threats.  An 
automated  tool  should  represent  the  threat 
behavior,  which  can  be  tremendously  complex, 
according  to  such  factors. 

In  representing  threat  behavior,  the 
connectivity,  or  dependency,  of  the  threats 
is  an  important  Issue,  even  If  the  only 
connectivity  Is  that  the  penetrator  will  have 
to  fly  over  the  defended  area  once  again 
during  egress.  Even  when  planning  a  single 
sortie,  the  element  of  surprise  Is  removed  as 
soon  as  the  first  radar  detects  the  presence 
of  the  penetrator.  When  threats  are 
networked  together,  threat  lethality  becomes 
a  function  of  threats  already  encountered. 
When  a  penetrator  Is  detected  by  a  threat, 
that  threat  Is  alerted  to  other  penetrators 
that  may  come  along.  Connected  threats  will 
also  be  alerted. The  result  Is  Increased 
lethality  as  the  penetrator  encounters 
alerted  threats. 

The  state  of  alert  of  the  threat  affects  the 
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lethality  of  a  discontinuous  path,  where 
exposure  to  a  particular  threat  or  threat 
network  is  intermittent,  as  well.  Because 
the  exposure  is  intermittent,  a  discontinuous 
flight  path  may  actually  have  a  lower 
lethality  than  continuous  exposure  over  the 
same  area  of  lethality.  The  second  and 
successive  exposures  will  encounter  an 
Increased  state  of  alert,  but  the  threat's 
readiness  may  have  changed.  For  instance, 
there  is  a  time  required  to  acquire  and  fire 
at  the  penetrator.  A  continuous  exposure 
may  give  the  threat  enough  time  to  react, 
while  intermittent  exposure  may  not  afford 
the  threat  the  opportunity.  A  realistic 
representation  of  the  threat  environment, 
then,  should  take  into  account  the  history  of 
penetrator  exposure  to  the  threat 
environment . 


_ FLAPS  ,  THREAT  ENVIMNMENl 

The  Force  Level  Automated  Planning  System 
(FLAPS)  is  a  mission  planning  tool  built  for 
use  in  European  theaters  of  operation  as  an 
aid  for  the  generation  of  the  Air  Tasking 
Order  (ATO)*.  Although  FLAPS  is  not  used 
extensively  by  USAFE  (United  States  Air 
Forces  in  Europe),  for  which  it  was  Intended, 
it  has  been  used  in  the  creation  of  exercise 
ATOs  and  is  well  known  in  both  the  Research 
and  Development  and  the  user  community.  It 
contains  algorithms  and  techniques  for 
incorporating  minimum  lethality  routes  in  the 
construction  of  candidate  missions,  and  is 
one  of  the  five  decision  aids  that  serve  as 
the  basis  for  the  development  of  the  Advanced 
Planning  System  (APS) ,  a  Rome  Laboratory 
effort  which  will  be  utilized  in  all  Tactical 
Air  Force  (TAF)  theaters  for  force-level 
planning. 

The  paths  generated  by  the  FLAPS  dynamic 
programming  algorithm  are  for  a  single  sortie 
of  a  generic  aircraft  type  exposed  to  the 
threat  environment  at  a  constant  altitude. 
Threat  modeling  in  FLAPS  consists  of  an  array 
of  cells,  each  cell  containing  a  lethality 
value.  The  lethality  value  is  arrived  at  by 
taking  the  negative  logarithm  of  the 
probability  of  survival  when  exposed  to  a 
threat  in  a  particular  location,  at  a 
constant  altitude.  Terrain  masking,  or  using 
the  terrain  in  the  defended  area  as  a  block 
to  detection  by  enemy  radar,  increases  the 
probability  of  survival,  and  is  considered  in 
the  calculation  of  the  lethality  value. 
Dynamic  programming  is  used  to  minimize  the 
sum  of  lethalities  along  a  path,  but  each 
cell  is  necessarily  considered  to  be  a 
separate  independent  event.  This  simplistic 
representation  of  lethality  Ignores  threat 
connectivity,  whether  it  be  by  communication, 
shared  radar,  etc.,  and  cannot  take  Into 
account  the  history  of  penetrator  exposure  to 
the  threat  or  threats. 

While  FLAPS  is  a  force  planner,  its  routing 
algorithms  are  insufficient  for  routing  force 
level  assets  for  the  creation  of  an  overall 
plan.  It  makes  no  provision  for  specific 


*  The  Air  Tasking  Order  Is  the  plan  for  the 
allocation  of  force  resources  for  the  next 
day's  plan.  It  translates  the  Joint  Force 
Cormander's  apportionment  Into  sorties,  by 
aircraft  type,  for  each  mission. 


aircraft  characteristics,  such  as  speed, 
weaponeerlng,  and  capability,  nor  does  it 
account  for  multiple  penetrators.  The  threat 
environment  is  static  and  cannot  account  for 
the  interaction  of  penetrators  within  the 
threat  environment,  over  time. 


6.  HERO  APPROACH 

Automated  force  planning,  represented 
realistically,  would  at  the  very  best  be 
difficult,  if  not  Irtposslble,  to  accomplish 
using  traditional  programming  techniques. 

The  use  of  such  techniques,  which  do  not 
offer  the  flexibility  of  object-oriented 
techniques,  cannot  easily  accommodate  the 
level  of  detailed  analysis  of  the  many 
variables  that  enter  into  "optimization''*  of 
mission  planning.  HERO  exploits  object- 
oriented  design,  using  it  as  a  platform  for 
the  dynamic  representation  of  the  planning 
process  and  of  the  variables  that  affect 
mission  accomplishment,  as  well  as  serving  as 
a  good  technique  for  organizing,  and 
providing  for  extension  to,  a  complex 
software  system. 

The  objective  of  the  HERO  effort  was  to  prove 
the  feasibility  of  using  object-oriented 
programming  techniques  in  automated  route 
generation  for  theater  level  mission 
planning,  utilizing  heuristics  where  possible 
to  reduce  the  number  of  options  that  must  be 
evaluated.  Object-oriented  programming 
provides  the  means  to  incorporate  those 
mission  planning  parameters  that  are 
impossible  or  impractical  to  Include  using 
other  techniques,  factors  that  are 
inextricably  associated  with  flying  a  route 
through  a  defended  area  with  the  best  chance 
of  survival.  It  allows  the  creation  of  a 
dynamic  environment  model  within  which 
planning  takes  place. 

Actual  missions  consist  of  the  Interaction  of 
real-world  objects,  therefore,  mission 
planning  should  be  concerned  with  such 
Interaction  as  well.  The  HERO  concept 
focuses  on  this  Interaction  of  objects. 

Within  the  HERO  scenario,  penetrators 
Interact  dynamically  with  threats  and  the 
environment,  including  terrain,  as  route 
options  are  developed.  Penetrators  are 
specific  aircraft  with  particular 
characteristics  and  capabilities.  HERO  can 
plan  multiple  missions  simultaneously,  at  a 
specified  altitude,  for  single  or  multiple 
sortie  missions,  taking  into  account  the 
command,  control,  and  communication 
relationship  among  threats,  and  the  potential 
effects  of  saturation  and  electronic  warfare 
capabilities  in  traversing  enemy  airspace. 

The  real-world  objects  are  translated  into 
the  "objects"  of  object-oriented  programming. 
Each  high  level  grouping,  or  class,  of 
objects  contains  all  the  shared 
characteristics  of  that  type  of  object.  The 
characteristics  of  a  class  in  object-oriented 
programming  are  defined  as  "instance 
variables,”  and  subsets  of  a  class  are 
"instances"  of  that  class.  New  members  are 
added  by  creating  new  instances  of  the  class 


*  For  the  purpose  of  this  paper, 
"optimization"  means  finding  the  best 
possible  route  under  the  given  conditions  and 
limitations. 
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Object,  and  each  Instance  either  uses  the 
default  value.  If  any,  for  each  Instance 
variable,  or  It  defines  Its  own  values.  The 
creation  of  Instances  makes  Increasing  the 
number  of  subsets  an  easy  thing  to  do.  Each 
Instance  can  "Inherit"  the  characteristics  of 
the  class,  and  have  characteristics  of  Its 
own,  without  a  lot  of  additional  coding.  For 
example,  although  there  are  many  types  of 
penetrators,  they  all  share  the  common 
characteristics  of  an  airplane.  Each 
penetrator  Instance  that  Is  created  has  the 
characteristics  of  an  aircraft,  such  as 
weight,  drag,  and  fuel  consumption,  but  the 
actual  values  may  be  different.  Figure  1 
shows  the  definition  of  the  penetrator  class. 
(HERO  was  developed  with  Symbolics  Flavors,  a 
Syinbollcs  extension  to  Common  Lisp,  where  the 
top-level  objects  are  called  FLAVORS.)  An  F- 
15E  Is  an  Instance  of  a  penetrator,  as  Is  an 
F-16A,  but  each  has  Its  own  unique 
characteristics.  This  type  of  flexibility 
and  ease  of  coding  makes  It  possible  to 
create  many  Instances  of  a  class,  as  well  as 
to  easily  add  to  those  that  already  exist  In 
the  program. 


(defflauor  penetrator 
((tail-number  0) 

(miesion) 

(mission-role) 

(airframe) 

(fuel) 

(uieapons) 

(ecm-assets) 

(total  drag  0) 
(maM-speed  0) 
(climb-rate  0) 
(service-ceiling  0) 

(range  0) 

0 

:initable-instance-var1ables 

ruirltable-instance-uariables) 


aircraft.  This  value  Is  derived  from  DELPHI 
data.  Determination  of  lethality  becomes 
Increasingly  sophisticated  as  more  variables 
are  factored  In  as  a  result  of  the 
Interaction  of  an  aircraft  or  group  of 
aircraft  with  the  threat  environment.  The 
routing  algorithm  gauges  the  cost  of 
encountering  a  threat  based  on  the  threat 
characteristics,  doctrine,  and  timing  that  Is 
extracted  from  the  state  transition  diagrams. 

The  threat  model  assumes  threats  to  be  In  a 
ready  state  Initially.  From  the  ready  state, 
the  diagrams  show  how  the  threat  behaves, 
based  on  time  factors.  The  threat  system 
requires  a  certain  amount  of  time  to  perform 
some  function,  or  change  Its  state,  and  these 
possible  transitions  are  represented  by  arcs 
between  the  nodes  that  represent  possible 
states  of  the  threat  system.  A  state 
transition  diagram  for  an  SA-8  battery  Is 
shown  as  figure  2.  The  transition 
Information  extracted  from  the  diagrams  Is 
used  to  construct  the  threat  objects  In  HERO. 
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Figure  1.  PENETRATOR  FLAVOR 

L. _ THREAT  EMVIRQNMENT 

Enemy  Command,  Control,  and  Communications 
(c3)  are  accounted  for  In  the  HERO  threat 
models.  The  behavior  of  the  threats  Is 
represented  as  transitions  from  one  state  to 
another.  In  some  amount  of  time.  Data  for 
each  threat  Is  assembled  on  state  transition 
diagrams.  The  diagrams  reflect  the 
generalization  of  behavior  when  Individual 
TELS,  RADAR,  and  Command  and  Control  (C^) 
components  are  considered.  The 
representation  is  simplified  by  forgoing 
consideration  of  mobile  threats,  assuming 
such  movement  would  not  lessen  the  overall 
threat  because  of  overlapping  threat 
coverage.  The  effects  of  saturation,  the 
network  of  threats,  and  Electronic  Counter- 
Measures  (ECM)  are  extracted  from  the  state 
transition  diagrams  and  built  Into  the  route 
planning  algorithm,  thereby  gauging  the  cost 
of  encountering  a  threat. 

The  Initial  lethality  value  for  an  aircraft 
over  a  particular  threat  is  based  on  altitude 
blocks  and  range  of  the  threat  to  the 


a, _ INTERACTIQH  QF  OBJECTS  IM  THE  THREAT 

ENVIROHMEMT 

The  objects  hold  "knowledge"  of  their  states, 
stored  as  Instance  variables.  The  threat  and 
radar  objects  contain  Information  on  what 
state  they  are  In  and  how  they  will  be 
affected  as  the  environment  changes,  e.g.,  a 
penetrator  Is  detected  by  radar.  The 
penetrator  object  keeps  track  of  the  changes 
in  weight,  drag,  and  on-board  EC  (Electronic 
Combat)  assets.  The  object  which  Is  the 
mission  is  then  able  to  "collect"  Information 
on  the  state  of  the  threats  It  passes  (l.e. 
alerted  by  another  penetrator,  out  of 
missiles,  etc.)  and  store  the  cost  of 
encountering  the  particular  threat,  given  the 
state  of  threat  and  penetrator  at  that 
particular  time.  The  lethality  value  that 
Che  threat  (object)  supplies  to  the  mission 
(object)  Is  based  on  the  expected  behavior  of 
the  particular  type  of  threat  (e.g.  SA-6), 
with  Its  particular  alert  history  and  current 
state  of  readiness,  when  It  Is  alerted  to  a 
certain  penetrator  type  with  a  specific 
weapons  load.  The  partial  routes  created  by 


91  11  13  OOi 


.1-4 


the  mission  object  are  evaluated  by  the  A*  lethality  encountered/  etc./  and  form  the 

("A-star")  search  algorithm/  using  a  best-  basis  for  evaluating  the  possible  missions 
first  search  technigue.  The  best  completed  against  each  other  to  find  the  best/  or 

route  is  chosen  based  on  lowest  heuristic  lowest  cost/  of  the  possible  worlds. (3:4-6 

cost.  4-7) 


9.  ROUTE  PLANNIHG 

The  HERO  planning  space  is  modeled  with  a 
region-based  approach.  The  airspace  is 
represented  geometrically.  The  airspace  is 
divided  into  AGL  (Above  Ground  Level)  planeS/ 
defined  as  the  airspace  a  fixed  distance 
above  the  ground  projected  onto  a  plane. 

Each  AGL  plane  is  then  divided  into  polygonal 
regions.  Overlapping  polygons  are  combined 
by  computational  geometry  such  that  each 
polygon  represents  an  area  of  homogenous 
characteristics.  Within  a  polygon,  any  route 
extended  will  encounter  the  same  lethality 
cost,  thus  avoiding  the  dilemma  posed  by 
search  through  adjacent  cells  of  equal 
lethality  in  the  kind  of  array  of  fixed 
lethality  described  in  paragraph  5.  To 
accomplish  region-based  route  planning,  the 
polygons  are  divided  into  triangular  areas 
(triangulated)  which  serve  as  a  basic  area  of 
traversal  in  generating  candidate  legs.  At  a 
given  AGL,  the  range  of  a  threat  or  radar  is 
a  cross-section  of  its  actual  three- 
dimensional  range,  therefore  representing  the 
danger  to  an  aircraft  flying  a  route  .through 
the  defended  airspace  at  a  given  AGL  (figure 
3)  . 


FIGURE  3.  Threat  Lethality  as  a  cross- 
section  In  AGL  plane. 

In  evaluating  partial  routes  extended  by  the 
mission,  HERO  uses  the  technique  of  "possible 
worlds."  The  search  tree  is  the  tree  of 
possible  worlds  in  the  planning  space,  and 
consists  of  many  "plan  worlds."  A  plan  world 
represents  the  status  of  a  mission  simulation 
at  a  point  in  time,  breaking  the  simulation 
down  Into  steps  or  actions  which  are 
evaluated  according  to  the  cost  of  executing 
that  step.  Such  costs,  which  are  extracted 
from  the  scenario  objects,  include  fuel  used. 


IQ.  TIME  AND  SPACE 

The  processing  time  for  route  planning  in 
HERO  is  significant.  The  HERO  effort  is  a 
development  model,  and  as  the  prototype  is 
resident  on  a  Symbolics  3650  machine,  which 
is  a  better  development  environment  than  a 
run-time  environment,  speed  was  sacrificed 
for  ease  of  development.  The  search  through 
the  tree  of  possible  worlds  becomes  larger 
and  requires  more  processing  power  and  memory 
space  as  more  variables  are  factored  into  the 
analysis.  During  demonstration  of  the 
system,  planning  ingress  and  egress  for  one 
mission  of  4  F-16's  through  twelve  threats 
(SA-6s  and  SA-8s)  took  approximately  1  hour. 
Although  this  is  very  discouraging,  the 
dynamic  threat  representation  holds  far  too 
much  promise  to  be  thrown  away  because  of 
time  considerations. 

The  geometric  representation  is  a  major 
factor  in  the  time  required  for  mission 
planning  in  HERO.  Because  branches  are 
generated  from  triangle  to  triangle,  too  many 
branches  may  be  created  Legs  that  are  too 
short  to  be  flyable  may  be  extended  as  well. 
The  trade-off  of  speed  for  local  homogeneity 
became  more  and  more  obvious  as  the  effort 
progressed. 


IL. _ SCENABIfl 

HERO  uses  the  Soviet  system  of  surface-to-air 
missiles  and  deployment  doctrine.  The 
scenario  consists  of  2  Fronts,  6  Armies,  19 
Divisions,  and  1  OMG  (Operational  Maneuver 
Group) .  The  Front  and  Army  units  consist  of 
air  defense  brigades  and  battalions.  The 
divisions  are  tank  and  motorized  rifle 
regiments,  and  air  defense  regiments  with 
associated  SAM  (Surface-to-Air  Missile) 
batteries.  The  OMG  consists  of  5  Brigades  and 
includes  combined  arms  regiments  and  air 
defense  battalions  with  their  SAM  batteries. 
In  order  to  preserve  the  unclassified  status 
of  the  HERO  project,  older  SAM  system  (SA-4, 
SA-6,  SA-8,  SA-9,  with  ZSU-23-4)  are  used. 
HERO  currently  uses  central  Europe  (Germany) 
for  its  scenario,  but  any  scenario  that  uses 
DTED  (Digital  Terrain  Elevation  Data)  can  be 
employed. 


12.. _ STATUS 

The  HERO  prototype  is  installed  at  Rome 
Laboratory.  It  clearly  demonstrates  the 
complexity  of  the  mission  planning  process  as 
well  as  the  benefits  of  object-oriented 
design  and  implementation.  As  the  emphasis 
of  tlie  HERO  effort  was  the  exploration  of 
route  planning  alternatives,  some  features  of 
the  user  interface  have  either  not  been 
Implemented  or  have  been  implemented  without 
flexibility.  One  of  the  key  Issues  that  HERO 
was  to  address,  overlapping  threat  envelopes, 
was  not  fully  developed  at  the  completion  of 
the  effort  and  stands  as  partially 
Impletnented. 


LL _ CQMCmSIQN 


One  of  the  most  Important  Ideas  to  be  gleaned 
from  the  HERO  effort  is  the  complexity  of  the 
task  at  hand.  If  the  goal  Is  to  Include  all 
factors  In  mission  planning  and  to  test  every 
possible  path  for  optimality,  the  run-time 
would  far  outweigh  the  benefits  of  such  an 
endeavor.  It  Is  well  known  that  there  Is  not 
much  to  be  gained  without  risk.  So,  while  we 
may  risk  missing  the  optimal  route  by  the 
application  of  a  well-placed  heuristic,  the 
outcome  will  be  a  very  good,  survivable 
option  that  may  not  have  been  obvious  had  the 
automated  tool  not  been  applied  at  all. 
Clearly,  It  Is  better  to  have  a  very  good 
route  with  low  lethality  and  othei.  costs, 
arrived  at  within  a  reasonable  amount  of 
time,  than  to  have  no  route  at  all  because 
the  optimum  could  not  be  arrived  at  In  time, 
or  one  that  Is  not  as  good  because  all  the 
parameters  cannot  be  considered  by  available 
automated  or  manual  means. 

The  key  factor  that  makes  HERO  a  model  for 
future  development  of  route  planning  aids  Is 
the  representation  of  the  threat  environment. 
HERO  Is  capable  of  planning  Individual  or 
multiple  sorties,  and  the  object-oriented 
approach  has  proven  to  be  a  practical  way  to 
insure  the  dynamic  representation  of  real 
world  objects  In  the  automated  environment, 
as  well  as  to  insure  the  flexibility  required 
to  encompass  additional  planning  parameters 
as  they  are  deemed  necessary  by  the  user. 
Although  a  system  like  HERO  could  be  useful 
in  planning  Individual  sorties  at  the  unit 
level.  Its  use  In  theater-level  planning 
shows  much  promise.  Application  of  the 
principles  demonstrated  by  HERO  would  allow 
the  planner  the  opportunity  to  not  only  put 
the  best  possible  resources  on  a  target,  but 
to  more  clearly  see  where  and  how  tactics  and 
strategy  can  be  incorporated  into  the  ATO. 
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Discussion 


1.  Gkn  Johnsoa,  United  States 

Does  it  frighten  you  to  use  independent  threat  models  when 
this  conference  is  on  using  MI  to  achieve  networking? 

Author 

There  are  interactions  in  the  system.  Comments  made  in  the 
talk  were  an  introduction  to  inadequacies  of  present  models. 

2.  George  Chapman,  United  States 

Can  your  system  adapt  its  heuristic  search  algorithm  for 
pilot  preference,  mission,  or  mission  phase  (i.e.  can  the 
method  you  use  to  evaluate  the  lethality  for  each  path 
change)? 

Author 

No.  There  has  not  been  an  interface  or  protocol  for  allowing 
such  changes. 

3.  Edward  Gfiatti,  United  States 

What  is  the  status  of  your  program? 

Author: 

The  fifth  prototype  is  installed  in  the  laboratory. 

4.  Dr  G.H.  Hunt,  United  Kingdom 

Could  you  give  some  more  detail  about  your  measurements 
of  the  system  performance  and  the  results  you  obtained? 

Author 

We  are  not  as  concerned  with  performance  for  this 
laboratory  demonstration  as  we  would  be  fora  system  being 
transitioned  to  the  field.  The  processing  time  is  really  very 
slow.  For  a  very  simple  scenario  of  four  F-  16s  flying  through 
SA'6s  and  SA-8s  environment,  I  believe  12  of  them,  it  can 
take  from  1  —4  hours,  depending  on  configuration  of  the 
planner.  We  are  considering  many  variables,  but  the 
representation  of  the  state  space  is  a  major  factor  in  the  long 
processing  dme. 

5.  Lyle  ReibUng,  United  States 

Since  using  A*,  what  information  goes  into  the  heuristic 
estimate,  and  is  it  an  underestimate? 

Author. 

Not  sure  if  it  is  an  underestimate.  Fuel  and  time  are  ba.sic 
information  for  the  heuristic  estimate. 

6.  Dr  M.C.Donkcr,  Netherlands 

You  mentioned  the  A*  algorithm  to  determine  optimal 
routes.  Is  there  any  room  for  pilot  preference?  And 
secondly,  would  you  not  be  too  pnKlictable  if  you  use  the 
same  heuristics  all  the  lime? 

Author 

Many  of  the  parameters  can  be  set  by  the  user.  As  for  us 
applyii^  heuristic  rules,  based  on  preference,  in  order  to 
limit  search,  my  experience  has  shown  that  one  pilot's 


preference  is  not  another’s,  but  each  believes  his  to  be  the 
correct  one.  There  are  actually  very  few  heuristics  in  the 
program.  They  are  basically  constraints  that  can’t  be 
violated. 

7.  T.Scfaang,  Prance 

What  is  the  depth  of  the  search  using  A*  or  what  is  the 
partial  leg  length? 

Author 

I’m  really  not  sure  if  I  can  say  what  the  depth  is.  We  have  not 
put  a  limit  on  depth  of  search.  Minimum  leg  lengths  is 
normally  configur^  by  the  human  planner.  We  have  a  value 
hardwir^  in  for  our  use  but  I  can’t  say  off-hand  what  the 
value  is. 

8.  Prof.  A.N.liice,  Turkey 

What  aspects  of  your  program  can  qualify  for  being 
‘intelligent"? 

Author: 

Object  oriented  programming  has  its  roots  in  artificial,  or 
machine  intelligence.  HERO  uses  objects  to  represent  the 
real  world  and  the  knowledge  contained  in  those  objects  can 
be  transferred  to  other  objects. 

9.  T.  Schang,  France 

As  mission  objects  collect  all  threat  state  information,  how 
do  you  manage  combinatorial  explosion? 

Author: 

While  processing  time  is  slow,  due  in  part  to  the  geometric 
representation  of  the  state  space  and  hardware  limitations, 
the  object-oriented  approach  does  not  have  the  problem  of 
combinatorial  explosion  that  other  methods  may  encounter. 

10.  W.E.  Howell,  United  Stales 

Do  you  account  for  uncertainty  in  hostile  aircraft  state 
vector  in  your  system? 

Author: 

Most  of  the  development  has  been  done  with  clean  data. 
Uncertainty  is  being  addressed  at  present  at  the  situation 
assessment  stage  rather  than  tactics,  which  will  follow  later. 
However,  we  have  done  some  checks,  to  ensure  that  the  plans 
do  not  fall  apart,  by  injecting  noise  as  data  mapped  from 
simulator  to  tactical  database  area.  This  will  pursued 
more  fully  as  we  go  from  initial  development  to  evaluation 
and  further  development. 

11.  J.Drtessche 

Please  elaborate  on  the  reasons  why  MUSE  was  preferred 
over  other  commercial  systems? 

Author. 

Primarily  the  features  offered,  including  windowing, 
downloading,  as  well  as  AI  features,  met  our  requirements 
and  close  working  contacts  with  supplier  gave  promise  of 
excellait  support  if  modifications  were  required.  Secondly, 
MUSE  weU  supported  on  Sun  workstations. 
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ADVANCED  SATELUTE  WORKSTATION  (ASW) 
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EO.  Bo*  3430 
Sunnyvale,  CA  94088-3430 
USA 


X.  SUMMARY 

The  Advanced  Satellite  Wsilcstation  (ASW)  was  proposed  and 
started  by  the  author  in  1986  as  a  low  level  independent 
research  and  develt^ment  effort  Its  goal  was  to  evaluate  the 
utility  of  expert  systems  in  military  satellite  testing  operations. 
It  quickly  b^me  apparent,  however,  that  the  rule  base  was  too 
limited.  This  project’s  goal  was  then  modified  to  capture  as 
much  of  the  factory  and  flight  experience  as  possible  in  an 
electronic,  updateable  medium.  The  resulting  electronic 
library  would  then  permit  much  deeper  insight  into  the 
satellite’s  operation  and  more  confidence  in  understanding  and 
expanding  the  expert  system  rule  base.  The  first  on-line 
demonstration  was  done  during  June  1990  in  one  of  the  Air 
Force’s  Mission  Control  Centers,  and  evaluations  of  ASW  are 
currently  underway.  Preliminary  results  are  very  encouraging. 


The  Department  of  Defense  supports  an  active  constellation  of 
60  to  70  satellites  today.  The  emergence  of  “LIGHTSAT” 
technology  and  PEGASUS  air-launched  boosters  may  reduce 
the  cost  of  booster  and  satellites  significantly.  This  is  expected 
to  dramatically  increase  the  number  of  satellites  which  need 
support  during  the  1990-2000+  timeframe.  One  might 
ot^rve  that  there  should  be  a  way  of  significantly  reducing  the 
corresponding  cost  of  ground  control  for  these  less  expensive 
LIGHTSATS.  The  “old”  way  of  doing  business  using  dedicated 
Mission  Control  Centers  (MCQ,  large  support  st^,  on-site 
contractor  support  and  highly  specialized  job  functions  may 
change  if  the  defense  budgets  continue  to  decline  while  the 
appetite  for  satellite  support  to  military  forces  continues  to 
increase.  This  situation  has  led  to  the  following  ASW  goals: 

-  Reduce  the  cost  of  ground  control,  especially  the  manpower 
requirements;  e.g.,  the  cost  of  training  and  maintaining  a 
large  staff  of  satellite  controllers. 

-  Provide  an  integrated  decision  sufiport  environment  for 
satellite  operators  to  reduce  the  number  of  “specialists,”  i.e., 
use  technically  competent  “^neralists.”  The  goal  would  be 
to  provide  these  "generabts”  with  the  right  type  of 
background  data,  in  a  form  they  could  easily  understand— a 
“decision  support  environment” 

-  Use  advanced  technology  to  automate  operator  tasks  when 
it  a  ai^nopriate;  e.g.,  let  the  madiine  do  the  repetitive  work 
and  let  the  enpneer  do  the  judgmental  work. 

-  Offload  the  primary  command  and  control  system 
processing  wwkload;  it.,  perform  computational  intensive 
telemetry  processing  and  diq)lay  fiinctions  with  an  offline 
computer. 

The  last  goal  reflects  a  current  loading  problem  in  the  Air  Force 
Satellite  Control  Network’s  "Commit  and  Control  System 
(CCS)”  in  which  only  3-4  siinaltaiieous  satellite  contacts  can  be 
rapporied  from  one  Mission  Control  Center.  ASW  couM 
ofi^  the  CCS  and  increase  the  overall  system  c^racity  by 
performing  more  telemetry  processing  in  a  separate  processor. 


Today,  satellite  specialists  are  used  to  periodically  support 
mission  control  team  personnel  u4io  have  significant 
experience  in  operating  many  satellites  in  a  large  control  center 
but  lack  expertise  in  individual  satellites  and  their  subsystems. 

The  ASW  design  started  as  a  concept  in  which  an  MCC 
operator,  with  some  previous  satellite  control  experience,  was 
envisioned  to  have  a  much  wider  variety  of  information  at  his  or 
her  disposal.  The  ability  to  understand  a  satellite’s  inner 
workings  was  needed,  and  to  do  this,  the  ASW  concept  was 
envisioned  to  include  elements  such  as  logic  diagrams, 
simulations,  expert  systems,  and  pictures  of  the  “as  built” 
satellite  to  provide  this  indepth  knowledge  (Figure  1).  The 
computer  aided  design  details  (left),  expert  systems  and 
waveform  analyzers  (center)  and  “as  built”  pictures  from 
factory  or  on  orbit  photographs  (right)  represent  the  new  types 
of  data  needed  by  the  satellite  operator.  The  functional  goals 
described  above  and  this  broad  concept  were  translated  into  a  3 
screen  workstation  design  illustrated  in  Figure  Z 


The  following  features  of  ASW  are  described  with 
corresponding  background  illustrating  why  each  feature  was 
included  in  the  system.  During  the  development  of  ASW,  the 
entire  system’s  data  base  was  generated  for  testing  the  joint  Air 
Force/NASA  satellite  called  Combined  Release  and  Radiation 
Effects  Satellite  (CRRESX  which  is  a  fairly  complex  scientific 
payload  with  more  than  40  instruments.  The  satellite  was 
launched  on  July  25,  1990,  and  most  importantly  for  the  ASW 
project  it  represented  an  unclassified  source  of  R&D  data 
which  was  significantly  easier  to  handle  than  classified  data 
from  operational  DOD  satellites.  It  allowed  easy  input  to  data 
bases  and  less  restrictive  configuration  control  over  software 
changes  for  this  prototype  environment  This  is  very  important 
if  qui^  progress  is  desired.  By  allowing  the  developer  an  easy 
method  of  changing  the  system  to  fit  the  operator’s  desire 
during  this  type  of  prototyping,  a  clear  statement  of  the 
requirements  is  an  output  of  the  process  rather  than  an  input  to 
a  classical  design-to-spec  activity. 

Telemetry  Display  System:  The  telemetry  display  was  built 
with  more  flexibility  than  the  somewhat  rigid  displays  of  the 
existing  Command  and  Control  System  (CCS).  Telemetry  point 
selections,  configuration  of  one  or  multiple  data  plots,  sc^ng, 
and  windows  were  basic  features  desired.  Selected  color 
displays  of  both  minor  alarms  and  critical  Umits,  forward  and 
backvt^  scrolling  of  data,  and  multiple  plots  using  different 
colors  were  additional  features  included  in  the  system.  It  was 
built  around  the  commercial  product  DATAVEEW  with  “C” 
code  enhatKements.  Figure  3  illustrates  one  of  the  screen 
displays.  The  key  feature  of  this  system  is  the  ability  to  change 
and  customize  the  diqrlays  in  realtime.  This  was  an  essential 
feature  that  the  techni^  advisors  wanted  to  augment  the  more 
ri^  display  in  the  primary  CCS  system.  Software  “buttons” 
are  placed  on  the  screen  so  the  analyst  can  select  features  and 
optfons  by  cliddng  a  mouse.  This  display  abo  alknw  the 
operator  to  ^  for  more  detailed  expert  syMem  advice  as  well  as 
supporting  information  contained  in  “hypercard”  displays. 

Rgpf.rt  .Systems:  A  typical  satellite,  contacted  through  a  remote 
tracking  station,  may  generate  between  3  and  30  minutes  of 
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Figure  1.  Advanced  Satellite  Workstation 
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ASW  Post  Pass  Expert  System 
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telemetry  data  for  each  realtime  contact  or  “pass”.  This  data 
may  be  merged  with  tens  to  hundreds  of  minutes  of  telemetry 
recorded  onboard  the  satellite  and  played  back  on  a  separate 
telemetry  channel  along  with  the  realtime  data.  The  result  is 
long  sequences  of  telemetry  data  w4iich  must  be  laboriously 
scanned  by  human  analysts.  ASW  was  set  up  to  have  an  expert 
system  (currently  with  90-100  rules)  for  the  electrita!  power 
s^tem  scan  all  of  this  data  in  a  few  minutes.  The  ruics  include 
simple  maximum/minimum  limits,  rate  of  change,  and 
combinations  of  rules  based  on  both  design  and  operational 
experience.  Any  violations  of  the  predetermined  rules  causes 
the  expert  system  to  select  the  offending  telemetry  waveform 
and  present  the  anomalous  data  to  the  operator.  The  expert 
system  automatically  calls  the  hypermedia  system  and  selects 
the  proper  section  of  the  Orbital  Operations  Handbook  - 
OOH  (an  “encyclopedia”  of  the  satellite’s  subsystem 
information).  We  foutul  that  many  satellite  controllers  do  not 
trust  expert  systems  .  ASW  tries  to  develop  their  trust  by 
augmenting  the  expert  system’s  terse  recommendations  by 
displaying  the  raw  data  which  triggered  the  recommendation, 
and  electronically  “pointing”  to  the  section  of  the  satellite’s 
OOH  which  explains  how  the  subsystem  should  qxrate. 
Figure  3  illustrates  the  types  of  messages  displayed  by  the  expert 
system  (at  the  bottom  of  the  figure).  It  also  states  how  many 
instaiKes  of  the  anomalous  behavkx  were  detected.  ASWs 
expert  system  is  configured  now  for  only  the  electrical  power 
$ubB]«tem(tfCRRES,batotl)ers»bsystemscanbeadded.  The 
commercial  tapttt  i]«tem  NBXFBRT  was  used  to  build  this 
appheation,  arid  it  executes  in  a  Sun/Unix  environment  ‘The 
developeis  created  the  first  expert  system  example,  including 
the  linkage  to  the  telemetry  d^lay  and  hypermedia. 


Subs^uent  subsystems  were  intended  to  be  generated  by  the 
satellite  technical  analysts.  To  date,  several  “rules”  have  been 
created  by  these  analysts  with  relative  ease. 

Hypermedia:  Discussions  with  eiqrerienced  satellite  analysts 
disclosed  that  many  types  of  information  are  used  to  support  an 
“expert’s”  knowledge  base.  These  include  the  logic  diagrams 
fixim  each  electronic  controller,  sample  waveforms  from 
previous  tests,  written  text  des^bing  correct  operational 
behavior  of  the  subsystems,  “as  built”  pictures  of  various 
boards,  assemblies,  subsystems  and  systems,  simulations, 
performance  curves,  and  finally,  simple  operator  experiences 
recorded  as  notebook  entries.  This  information  existed  in 
many  different  forms  and  was  difficult  to  organize.  Mr.  Stewart 
Sutton  analyzed  the  situation  and  decided  to  try  various 
scanning,  storage,  and  display  techniques  to  capture  the  data  in 
a  technique  called  multimedia.  Macintosh  scanners  were  used 
for  text  and-graphics  data,  video  tape  pictures  were  converted  to 
a  12-inch  laser  disk  for  a  >^te  Once  Read  Many  (WORM) 
drive,  and  logic  diagrams  were  converted  to  a  modeling  system 
written  in  C  code.  The  entire  system  was  organized  around  a 
“^int  and  fetch”  type  data  base  system  called  HyperCard  (see 
Figures  4-7).  The  multimedia  ^pe  information  under  the 
controlled  access  of  Apple  Macintosh  HyperCard,  is  called 
hypermedia.  The  application  of  this  HyperCard  technique  for 
ASW  was  termed  the  Information  Navigator,  and  selected  parts 
of  three  volumes  of  the  Orbital  Operations  Handbook  were 
scanned  or  hand  typed  into  the  system.  Anqreratcnrcan  now 
“navigate”  through  the  information  stadcs  at  his  or  her  own 
pace,  arxl  can  bro^  in  the  order  which  makes  sense  fen'  that 
particular  investigation.  The  Tblemetry  Display  System,  tlw 
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Figure  5.  Information  Navigator  OOH. 
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Expert  System,  the  Hypermedia,  and  the  non-machine 
interfaces  combine  to  form  the  basis  for  the  “Decision  Support 
Environment.” 

Modeler  Logic  diagrams,  performance  curves,  and  text 
descriptions  b^uently  do  not  dearly  describe  the  electronic 
control  logic  which  exists  in  each  of  many  satellite  subsystems. 
Mr.  Peter  H(»neier  generated  an  easy-to-use  logic  description 
which  starts  at  a  Ugh  level  “box/input/output”  view,  and 
proceeds  in  a  hierarchical  ^hion  to  successively  lower  and 
lower  elements  within  the  subsystem.  The  approiih  is  to  lead 
the  user  froth  simple  descriptions  to  more  detailed  descriptions 
in  successively  more  detailed  representations;  unfortunately, 
time  did  not  allow  for  a  specific  application  of  Modeler  within 
this  version  of  ASW  for  the  CRRK  satellite. 

Automated-Ccaitact  Support  Plan  Generator  The  ASW  is  a 
type  of  electronic  “tool  box,”  which  includes  a  collection  of 
support  programs;  e.g.,  the  telemetry  scroller,  expert  systems 
hypermedia,  and  laser  disk  storage  of  still  and  motion  pictures 
of  the  spacecraft.  It  is  based  on  tbe  goal  of  redudng  workload 
and  increasing  the  effectiveness  (knowledge)  of  the  mission 
control  staff. 

The  staff  was  shown  the  first  prototype  of  ASW  and  was  asked 
to  identify  additional  functions  which  were  labor  intensive  and 
could  be  streamlined.  A  primary  candidate  was  the  routine  task 
of  manually  generating  a  “Contact  Support  Plan;”  i.e.,  a  time 
ordered  list  of  commands  and  actions  which  must  be  executed 
during  a  routine  satellite  contact.  The  pass  plan  is  done  dozens 
of  times  per  day,  thousands  of  times  per  year.  The  automation 
of  these  functions  now  includes  a  windows-based  text  editor 
with  “fill-in-the-blank”  capabilities,  utilizing  both  automatic 
and  user-selected  information.  The  output  is  a  laser  printer 
version  of  the  pass  plan  in  a  format  that  everyone  is  accustomed 


to  seeing,  but  which  is  faster  and  more  accurate  than  the 
manual  methods.  Figures  8  and  9  illustrate  two  screens  of  this 
system,  where  relevant  data  is  being  electronically  transferred 
and  accepted  by  the  qrerator  to  generate  both  the  header  and 
body  of  the  pass  plan.  Data  relevant  to  the  individual  pass  (e.g., 
station  name,  rise  time,  elevation,  fode  time,  etc.)  are 
automatically  retrieved  and  inserted  within  the  plan. 
Templates  for  standard  command  plans  (e.g.,  “VCR  read  out”) 
are  retrieved  and  inserted  into  the  commit  list  file. 

Timeliner/Scheduler  Planning  and  operation  of  an  R&D 
satellite  includes  the  time  phased  planning  of  many 
experiments  throughout  the  satellite’s  life.  These  operiments 
must  be  correctly  interlaced  with  realtime  contacts,  other 
experiments  orbit  constraints  (light,  dark,  apogee,  perigee, 
etc-X  and  tape  recorder  limitations.  A  graphical  experiment 
planner  was  aeated  called  Timeliner  which  can  illustrate  these 
constraints  and  options  on  one  page.  The  data  can  be  added, 
deleted,  moved,  or  modified  via  mouse  actions,  and  the  ou^ut 
sent  to  a  laser  printer  for  review  by  various  team  members. 
Figure  10  illustrates  a  sample  output  for  several  days  of  the 
CRRES  mission. 

S.  ETHERNET  CONNECTION  TO  THE  COMMAND 
AND  CONTROL  SEGMENT  fCCSl 

Any  type  of  workstation  which  analyzes  satellite  telemetry 
ne^  decommutation  and  engineering  unit  conversion 
functions.  ASW  uses  the  services  of  the  Air  Force  Consolidated 
Space  Test  Center’s  (CSTC)  facility  to  perform  the  functions  in 
the  IBM  4381  computer  system  eddied  Command  and  Control 
System  (CCS).  Telemetry  data  is  received  at  a  remote  tracking 
station,  relayed  to  Sunnyvale,  California,  routed  to  a  Mission 
Control  Center,  and  processed/stored  by  the  CCS.  ASW 
terminals  are  connected  to  an  Ethernet  which  is  fed  by  a  file 
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Figure  8.  Automated  Contact  Support  Plan  Generator 


Figure  9.  Automated  Contact  Support  Plan  Generator  (Body/Editor) 
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Figure  11.  System  Configuration 


server  attached  to  CCS  (see  Figure  11).  The  data  is  retrieved 
from  an  archive  disc  and  sent  to  the  Ethernet  in  a  file  transfer 
process  so  that  ASW  can  access  the  data  repeatedly  without 
loading  the  CCS  with  many  requests  for  service. 

6.  TEST  CASE  IN  MISSION  CONTROL  CENTER  VI 

The  process  of  building  ASW  reached  a  milestone  in  July  1990 
when  the  laboratory  version  was  moved  into  an  operating 
environment— Mission  Control  Complex  VI  at  the  CSTC  in 
Sunnyvale.  The  functions  of  ASW  currently  being  evaluated  in 
the  operational  environment  are; 

Training— Using  Hypercard/Hypermedia  services  of  the 
Orbital  Operations  Handbook  (OOH)  to  train  Planner/ 
Analysts  (PA). 

Data  Browsing— PA  analysis  of  electrical  power  system 
performance  by  using  the  expert  system  to  apply  90  to  100  rules 
to  the  record^  data  identifying  unusual  waveforms.  The 
telemetry  display  system  then  allows  the  user  to  judge  for 
himself  if  the  waveform  is  benign  or  anomalous. 

Anomaly  Support— Using  the  telemetry  system,  hypercard, 
video  picture,  and  modeler  to  analyze  various  subsystems 
(Modeler  is  not  equipped  with  a  CRRES  data  base  as  of  this 
writing) 

Pass  Planning— PA  using  the  automated  Pass  Planner  to 
improve  the  speed  and  accuracy  of  the  pass  plan  generation 
process. 

Experiment  Planning— Contractor  Technical  Advisors  using 
the  Timeliner  to  plan  many  of  the  thousands  of  experiments 
and  support  requirements. 

Several  very  useful  suggestions  were  received  from  the  support 
team,  logged  by  an  Aerospace  Corporation  engineering  intern, 
and  relayed  to  the  design  team.  Ttw  updated  version  of  ASW  is 
now  available  for  use  as  an  engineering  tool.  The  long  term 
goal  is  to  generate  a  final  report,  to  highlight  the  successful 
features,  and  include  these  features  in  a  Technical 
Requirement  Document  (preliminary  A-Spec)  for  future 


procurement  of  a  fully  documented  and  supported  satellite 
woricstation  section  for  the  Air  Force  CSTC. 

7.  FUTURE 

The  limited  time  and  funding  of  ASW  did  not  allow  all  of  the 
ideas  to  be  developed  and  implemented.  The  tyjres  of  problems 
encountered  resulted  in  the  following  enhancements  that 
should  be  included: 

1.  The  use  of  new,  high  quality  video  cameras  for  taking  the  “as 
built”  pictures. 

2.  A  technique  for  transferring  the  video  pictures  directly  fiom 
a  camcorder  to  a  read/write  laser  disk.  (The  process  now 
involves  “mastering”  on  a  1-inch  master  tape,  then 
employing  a  $2000  transfer  procedure  to  “bum”  a  12-inch 
laser  disk.) 

3.  Addition  of  a  data  base  manager  to  organize  and  maintain 
telemetry  files  on  the  SUN  workstation, 

4.  A  better  laser  disk  to  increase  storage  capacity  in  the  Sun 
Workstation  for  telemetry  files  (e.g.,  1-2  gigab;^e  capacity) 

5.  Improve  the  ease  of  acquiring  OOH  (satellite  technical 
data);  e  g.,  contractually  task  contractors  to  deliver  these 
OOH  documents  in  hypercard-compatible  formats/media. 

6.  Establish  interfaces  so  any  expert  system  and  telemetry 
processor  can  access  each  other’s  data 

7.  Determine  the  cost  (in  man  months)  to  deliver  a  similar 
system  for  the  next  satellite  mission.  Given  ASW  experience 
and  the  enhaiKements  above,  how  long  would  it  take  to 
acquire  the  satellite  data  and  input  to  a  fully  populated  ASW 
database  for  each  satellite  subsystem. 

The  ASW  designers  and  users  encoun^  the  collective 
community  of  spacecraft  builders  and  operators  to  share  similar 
accounts  of  success  and  problems  with  experiments  such  as 
ASW.  This  type  of  cooperation  will  help  miuce  the  support 
costs  associated  with  all  DOD,  NASA  and  civilian  spacnaafL 


ar  • 


CmmHl  PART  NOTICE 


This  paper  is  a  COMPONENT  PART  of  the  follwins  COMPILATION  report: 


The  component  PART  is  provioed  here  to  allow  users  access  to  individually 
authored  sections  of  Proceedings^  Annals^  Symposia^  etc-  However,  the 
COMPONENT  SHOULD  be  considered  within  the  context  of  the  overall  compilation 

REPORT  and  NOT  AS  A  STAND-ALONE  TECHNICAL  REPORT- 


The  following  COMPONENT  PART  nunbers  comprise  the  COMPILATION  report: 
-AD#:  .  TlTLEt.. _ _ _ 


AD-P006  330 


A  SniBRaiSTIC  APPROACH  TO  RXASONIMO  POR  AOTOMOMOUS  SATELLITES 


Captain  Janaa  M.  Skinnar 
Pkilllpa  Lalioratory 
Kirtlai^  APB,  MM  S7117 

Profaaaor  Oaoraa  P.  Lugar 
Oaivarsity  of  Maw  Maxioo 
MM  S7131 


Oaivarsity  of  : 
Alkuquarqua, 


Basecyon  our  earlier  research  [1,2],  %ie 
ace  aanwmed  that  the  best  Vdy  to  t^^coach 
ptcbloaF  solving  tadcs  is  not  tnrauch  any 
single  asthod  a£  reasoning,  but  by  a  mithod 
that  %dll  allow  several  reasoning  nethods 
to  be  blended  together.  The  thrust  of  this 
effort  is  to  develop  a  synergistic  asnroeKh 
to  reuoning  thattoU  allow  a  systan  to 
rely  on  sultiple  reasoning  sethodologies, 
thus  benefiting  fron  the  strengths  or  each 
of  the  reasoning  nethods,  while  minimizing 
their  respective  wedcneeses.  Ihis  paper 
dinounonn  the  steps  we  have  taken  towards 
developing  such  a  system,  which  are:  (1) 
the  categorization  of  reemoning  meUwos, 

(2)  the  selection  of  reasoning  approaches 
to  blend,  (3)  design  of  a  framewark  to 
blend  the  eysteae,  and  (4)  propcsed  tasks 
to  investigate  the  result.  ^ 


Research  in  Artificial  Intelligence 
(AI)  is  soamtiiges  partiticned  into  two 
Sfiroaches:  a  psycnologlcal  approach  which 
eeploys  AI  proutams  as  useful  tools  for 
studying  the  mind,  and  an  engineering 
apprimch  which  uses  AI  prograas  to  solve 
probleBB,  regardless  of  their  siadlarlties 
to  husan  reasoning.  Wills  this  effort  is 
oonoemed  %d.th  the  latter  approach,  it  is 
useful  to  examine  the  reascmng  methods 
used  by  tueans  to  guide  us  in  modeling  a 
reasoning  approach  for  aachinas. 

Wien  nsBuiB  reason  they  rely  on  maiv 
different  reasoning  techniqueB,  including: 

(1)  relying  on  memory  of  p^  cases  whan 
solving  problems  which  are  similar  to  these 
pest  cases. 

(2)  using  heuristics,  or  rules  of  tlwb, 
when  oonfronted  trith  a  familiar  situation. 

(3)  foUowing  a  proosdure  to  solve  a 
problem. 

(4)  developing  a  mental  aodel  of  the 
problem,  or  referring  to  a  Hftwmatlr  to 
diagpiose  problems  in  a  oagplex  system. 

(5)  ucmpaiing  an  unfamiliw  problem  to  a 
past  problem  (and  solution)  from  a 
differant  domain. 

(6)  using  a  formal  logical  asthod  to  prove 
a  thaorme  is  trua. 

The  msthods  outlinad  idiove  ara  by  no 
means  an  eadmustiva  list  of  human  reasoning 
methods.  ISmy  do,  howmvsr,  lepe  esent  a 
sMBile  of  msdiods  that  hwans  use.  Ha 
aiigfit  wiWi  to  aWc  if  a  oamzitsr  could 
reiMwn  in  a  similar  aathodT 

First,  wm  aust  address  ttw  guastlcn  of 
wiMthar  a  sschina  is  capaWe  or  zsasoning. 
Wills  sntizs  books  havs  bsan  writtmi  on 

«|»jsctM.  [3,4,5],  wa.wUl  skyep 
ttw  Issue  by  dsf  ining  zsasoning  as  "tha 
drawing  of  Infaesnoaa  or  oonclusians  from  a 


set  of  facts  or  suppaeitions."  Wmn 
oonfined  to  this  definition,  few  people 
will  disagree  that  not  only  is  it  possible 
for  acapuurs  to  reason,  but  that  nany 
alreacy  noBsoeo  this  opability. 

Wioi  niis  in  mind,  we  can  see  that  mech 
of  these  reasoning  methods  have  been 
automated  to  soam  degree  as  (l)  case-based 
reasoning,  12)  zuls-based  reasoiing,  (3) 
cxznventional  reasoning,  (4)  model-besu 
reasoning,  (5)  analogical  reasoning,  and 


Wiile  it  is  doubtful  that  we  will  ever  be 
able  to  autoaate  the  husan  reasoning 
process,  a  gcxxl  facsimile  might  come  from 
developing  a  systan  that  is  able  to  oonbine 
seme  or  all  or  these  reasoning  techniques. 
Before  we  discuss  how  that  might  be  done, 
it  %«uld  be  useful  to  develop  a  scheme  to 
categorize  the  different  methods  of 
reasoning. 

Severed  schemes  are  possible  for 
classifying  reasoning  methodologies.  Past 
approaches  have  included  classizication 
based  on  the  degree  of  precision  (e.g., 
sound  versus  fUziy  reasoiing)  or  degree  of 
generality  (gamral  purpose  versus  special 
purpose  reasoning) .  The  approach  talcen  in 
this  paper  is  a  classif  icaHon  based  on 
what  we  call  the  'Hlepth"  of  reasoning. 


Raasoning  methods  can  be  categorized  as 
"WiallcM"  or  ■Viego,”  depending  on  the  type 
of  knowledge  usea  in  the  wstem.  An 
approach  taken  Harmon  (Figwe  l)  is  to 
clasBify  knowledn  into  three  levels:  (1) 
heuristic  or  shallow  knowledge,  (2)  domain 
knowledge  (includes  procedural  models)  and 

(3)  de^  or  theoretical  knowledge  [6]. 
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Figure  1.  Three  Levels  of  Khowledge  [6] . 

To  iUustrats  this  knowlsdgs 
clawsifinetion  schema,  Harmon  oonsiders  how 
a  non-tacbnical  pareon  would  raaa^  if  their 
talsvision  sat  did  not  work.  Fizst.  ha 
si^  check  to  sea  if  it  was  plug^  in. 


If  ao,  te  rivka  Urn  oocd  and  switch 
all  of  tha  kncba  on  and  off  aevaral  tiaea. 
If  all  of  this  failed,  the  person  wold 
danida  ha  neadart  to  take  tha  TV  to  the  ahcp 
or  purchase  anothar  one.  This  paracn  has 
only  Lswel  1  knowledoa  of  telsNlslan  sets. 
It  oonsists  of  a  few  heuristics  that  he 
acplias  to  televisions,  toastsce,  and  other 
electz'ioal  devioas. 

If  tha  parson  takes  the  TV  to  a  repair 
diop,  he  aagpects  the  zapair  person  to  have 
■uch  aora  knowledge  about  tadevislons.  The 
repair  person  has  level  2  knowledge  of 
televiuon  sets;  ehe  probably  doea  not  have 
an  eelvanoed  degree  in  electroiics  or 
understand  tha  physics  of  television,  taut 
she  has  dosedn  or  procedural  knowledM  of 
televisions  and  Tv  repair.  Tha  dosaon 
nodal  includes  nary  heuristios  about  how  a 
ealfUneticn  in  one  oosponant  micfnt  indixse 
syeptoBB  elsauhera;  ttie  prooedural  nodal 
prcnddee  her  with  a  sta^by-stap  approach 
&  troubleehooting  tha^.  The  repair 
person  can  rely  on  both  nodels  to  guide  her 
in  the  syetasetlc  diagnosis  of  the  TV  set, 
and  in  selecting  an  appropriate  repair 
strategy. 

If  you  wanted  to  design  a  new 
television,  you  oould  probably  find  aoeieone 
in  an  anginaerlng  depaitnent  of  a 
universiw  who  understands  how  televisionB 
worked.  This  parson  has  Laval  3  knowledge 
of  television  sets.  Ha  probably  can't  fix 
your  television  set,  taut  he  has  thi 
underlying  or  deep  janowledga  of  ptralcs  and 
elactzcnics  that  would  enable  his  to  create 
a  device  that  would  function  as  a  TV. 

Na  can  extend  this  knowledge 
claasificatlon  schon  to  reasoning  systeeB. 
As  might  be  expected,  traditional  eigiert 
systasB  (i.e..  rule-cased  systas)  are 
associate  %d.ih  fallow  knowledge;  they 
rely  on  heuristic  knowledcpe  to  solva  a 
prooleB.  Appropriately,  we  will  refer  to 
these  aystaie  as  ^lallow  reasoning  aystaae. 
Oonventlonal  syataae,  which  norsally  anoode 
,  will  be  oonsiderad 


procedural  knowladgn,  will  be  ooi 
ois  eidpoirit  bstwean  ahallow  and 


anoode 
red  as 


reasoning  mymtmm.  AutcBatad  reasoning 
lystaan  (i.e..  thaorea  provacs)  are 
asBoclated  trioh  daap  knowledge,  and  will  be 
called  deep  reaaoning  mstaae. 

ftianaKcandlng  tt^  claasificatlon 
arhnaa  to  reasoning  ayetana  in  general  a 
problaai  arieaa;  thscrlae  can  be  encoded  in 
rules,  and  haurlstica  can  be  represented  as 
Bodale.  Th  account  for  this,  we  will 
eodify  tha  definition  slightly. 

To  dassify  a  reasoning  s^tas  as 
ahallow  or  dmp,  we  will  conaidM:  whether 
^  lyetaai  uaaa  an  iipllcit  or  a9g)licit 
nodal  of  tha  doeain  wfieti  reasoning.  Tha 
doeain  modal  im  oonaidarad  lixillctt  if 
tiwre  is  no  distinction  bstwean  different 
types  of  knowledga.  Rule-besed  ^stams  are 
an  they  uae  heuristic  knowledge 

arising  mm  naiiy  dlffirent  souroas  (s.g. , 
aapirioal  knowledga,  structural  knowlad^, 
cBuaal  knowladgB}  Mil  will  often  aaahina 


diffimmnt  types  of  knowdadga  into  a  singla 
rule  withm  distinction.  A  aystam  using 
an  implicit  domain  modal  will  ba  oonsidars 
a  mUiow  leaaening  aystam. 


The  doamin  model  is  aansidered  aaollcit 
if  a  distinction  is  made  between  ttie 
different  eouroae  of  knowledge.  The  types 
of  knowledge  and  tha  role  that  each  plS^ 
In  BTcfiidu  unlvlm  riTmnn  is 
clear.  As  an  exanple,  a  aysten  that  nodels 
tha  aubocaponents  of  an  electronic 
aaafxmmit  and  describes  the  relationship 
batwaan  the  ooeponents  is  an  exanple  or  a 
system  omiloying  an  explicit  dcmwin  model, 
and  WDUla  be  aansidered  a  deep  reasoning 


ftiila  there  is  a  tendency  to  attach  a 
bad  oomotation  to  the  term  diallow,  this 
is  not  justified  with  reasoning  sysceBiB 
(oonsidBr  that  MVCIN,  a  very  suoaessful 
aaqpert  aysten  used  to  diagncse  meningitis 
infections,  contained  onW  shallow 
knowledgh) .  Bach  form  or  reasoning  has 
strengths  and  weakneaaes.  The  applicaition 
ahoula  dictate  which  form  of  reaaoning  is 
used. 

^plications  that  require  the  systea  to 
cmture  aaqperiantial  knowledge  are  well 
suited  for  diallow  reasoning  systeoB.  This 
type  of  knowledcpe  is  easily  encoded  into 
eapiricel  associations.  Oonsider 
denmloping  an  expert  system  to  capture  the 
knowleoge  of  a  retiring  technician.  The 
technician's  knowledcpe  has  been  epathered 
over  the  years  from  many  different  sources 
and  is  best  represented  as  an  implicit 
model. 

However,  the  lack  of  explicit 
representation  of  more  fundamental 
knowledge  cam  caoise  some  serious  problons. 
These  probleBB  include:  (1)  rapid 
degradation  outside  the  narrow  demain  of 
eipertiae  of  an  expert  systae,  possibly 
leading  to  inoonslete  or  inoonrect 
conclusions;  andf  (2)  the  inability  to 
transfer  knowledcpe  to  other  tasks.  This 
inability  stems  nram  the  fact  that 
heuristics  are  usuzdly  task  epecific;  rules 
written  for  the  diagnosis  of  a  exaponent 
wrill  not  normally  be  useful  in  an  expert 
system  developed  to  design  the  cxxqpcment, 
even  thou^  the  underlying  mechanism  and 
g|y|ucail  princciples  are  the  same  for  both 

Diagnosis  of  man-made  devices  is  a  good 
applicstion  area  for  a  deep  reasoning 
system.  Bapecially  if  the  devics  is  a 
cxaplex  state  of  the  art  cxeponent  with 
little  or  no  expertise  enndlable.  The 
explicit  model  of  the  deep  reasoning  systan 
allows  the  eysbem  to  respond  to  situations 
that  oould  not  have  been  predicted.  But 
developeent  of  the  eoplidt  domain  model 


deep  raaecning  inappropriate  for  areas 
whioi  are  not  well  undosbood.  In 
madicine,  for  exaaple,  most  of  the 
knowledge  vmed  for  diagnoeing  and  treating 
rtleoweae  is  mapiriema,  not  based  on  a  model 
of  ^  relevart  biologioal  and  chmaioal 


Wiile  reasoning  amthodolcnias  do  not 
ncnmdly  rely  purely  on  ahallaw  or  deep 
raaecning  techniquas,  wa  propose  that  they 
can  ba  broadly  oabagorizad  as  one  or  the 
othmr.  Returning  to  the  three  levels  of 


XncwladgpB  at  Flour*  1,  m  claio  the 
rMoonina  —thoaologio*  can  faa  plaoed  in 
ncrraiiwnfiiiri*  «dth  th*  lavels  of  knowledgr* 
as  ahewn  in  Flour*  2.  ttiis  paper  ve 
%rill  c<1*in,is*  urn  ttare*  ahaUcw  xaascning 
aeOiedtologi**  (o*a*-loas*d/^xul*-tes*d,  and 
ooiWHitianal)  and  on*  at  uis  daap  raacnning 
■etfaodPlogies  (nodal-tasad) . 


nany  dcnains  have  existino _ _ 

(e.g. ,  Medicine,  laar)  ttiK  could  be  used  as 
a  seed. 

nrisary  ccnoenis  with  CER  are:  (1) 
organizing  cases  in  iwarry,  (2)  selecting 
the  relevant  oases,  and  (3)  Modifying 
eadsting  cases  to  fit  nsw  pcoblaae.  All  at 
these  areas  are  current  topics  of  research. 

Case-based  zeasoning  is  suitable  for 
dcaains  involving  clasufication  (Medical, 
legal,  planning)  and  pcableat  solving 
(design,  aathontics,  diagpusis) .  OBR  is 
best  suited  to  dcnains  in  %diich  Many 
training  cases  are  available,  and  vnere  it 
is  difficult  to  specify  mropriate 
racx  rules. 


behavior  using  abidzad 


I Facts 
Heuristics 
Procedural  Hodels 


Role^ased 

Conventional 
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Oontrary  to  pc|wlar  laali«f ,  AI 
advocates  do  na£  propooo  diat  all  QroblaBS 
dmild  te  aolvad  with  AI  tools. 
Oonvantioial  progEasadin  ssOiodB  will 
suffioa  in  nany  uirtmcas.  Table  1  lists 
the  dif feranoas  between  oonvantional 
systMS  anl  AI  ^stOH. 


labla  1.  OB^pariaom 
Systema  (»J. 

oomvantloaal  and  AI 

Oonv«ntifflnal 

AT  flyaV-jM 

Repreeerdation  and 
use  of  data 

Representation  and 
use  of  knowledge 

Algorittmic 

Heuristic 

Repetitive  Rreoess 

Inferential  process 

Effective 
manipulation  of 
large  data  bases 

Effective 
manipulation  of 
knowledge  bases 

Many  Frablaas  are  best  solved  fay 
oonventional  aragFBBedng  [91.  For  exaa^le. 


probleas  which  have  tractwle  natheaatical 
solutions  such  as  solving  dif f erentiad 
equations  %d.th  nuaarical  analysis 
techniques  are  net  anrqpriate  for  AI, 
while  problaBB  requiring  algetraic 
siaplizication  lend  thaaselves  cadte 
readily  to  sj^sbolic  reasoning.  Roblans 
that  can  be  solved  vrith  alocritlns  (focnal 
prooeduras  that  quarwitee  the  ocrract 
solution  every  tlsa)  are  better  left  to 
ocnventional  aysUasi.  For  exanple,  it  is 
sore  cost  ttCfectiva  to  sort  lists  with  a 
conventional  ayatai  than  with  an  AI 
{cagraBi. 


%e  f  ir^  of  the  deep  reasoning  sfsteeiB 
to  be  rtisnsisafl  is  aodalHaased  raraoning. 
Modal  based  reasoning  uses  an  coplicit 
aodel  of  a  aMstaai  to  describe  the 
coeponents  of  a  phy*lced  systaai,  the 
connections  between  the  coaponants,  and  the 
behavior  of  eerh  of  the  oosponants  [10]. 

The  aysteai  is  able  to  reason  about  thyeical 
laws  which  apply  to  the  systan,  ana  the 
affect  the  lawe  nay  have  on  the  system. 

Diis  forn  of  raasoriing  allcwn  for  a  aore 
robust  reepensa  to  a  previously 

Modal  based  systems  oosmonly  use  causal 


Modal  ijassd  afystams  oosmaniy  use  causal 
reasoning,  reasoning  from  first  principles, 
and  reasoning  from  am  princdpls  of 
locality  in  solving  a  problsm.  causal 
reasoning  relies  on  knowledge  oonoaming 
how  the  behavior  (or  miabdSvior)  at  oiw 
coaponmit  affects  ths  bahsvlar  or  anothar 
ooaponant.  Masening  from  first  principlss 
rhlisB  on  ths  laws  of  physics  or 
sattmmstirm  to jprsdiot  or  saplain  bahsvlar 
of  a  sytem.  Tna  principls  at  looaU^ 
oonsldsni  how  oosponants  are  connsetso 
hHchanigsUy,  slsctriflslly,  pbyidcaUy)  in 


can  bs  Influmioad  by  snot 
His  strength  at  modal- 


lies  in  their  fundamental  Knowledge  of  the 
domain.  Ihis  rdlowe  the  aystem  to  reason 
about  situations  previously  unencountered, 
and  for  which  the  aystem  has  not  been 
esplicitly  prograamed.  The  type  of 
knowledge  raprasentaticn  also  allowa  the 
knowledge  to  be  transferred  to  other  tasks; 
that  is,  a  model-based  eystae  originally 
develqpu  for  diaigrxstics  would  be  of 
significant  value  when  developing  a  design 
eoqpert  ^staa  for  the  saoae  domain  whereas 
knowledge  from  a  diagnostic  rule-^msed 
eystem  is  of  questionable  value. 

Die  weaknesses  of  a  model-^ased  systan 
become  apparent  only  when  it  is  a  pure 
nodel-Hmsed  systaa;  that  is,  then  no 
heuristics  2ure  used.  Diagnostic  searches 
threuA  ocepenents  of  syEccens  based  on  the 
princ^ls  ox  locedity  make  sense  only  if 
all  ooeponents  are  equally  fallible  and 
equzdly  accessible.  Otherwise,  rules  are 
essential.  In  fact,  nary  cases  can  be 
^lown  where  model-Htmsed  reasoning  requires 
more  time  than  ruleHoased  systesis.  For 
this  reason,  most  model-H»sed  systems  will 
include  at  least  a  few  rules  to  improve 
perfonnanoe. 

In  a  subsequent  section  we  argue  for 
blending  these  four  reasoning  neuiods  to 
produce  a  synergistic  effect.  Vie  cl2dn  a 
modified  blackboard  is  a  suitable  framework 
for  merging  the  individuzd  reasoning 
methodologies.  The  traditionEa  blackboard 
architecture  is  disraggyd  neoct  to  provide  a 
foundation  for  these  arguments. 


The  blackboard  architecture  was 
developed  for  a  speech  understanding  Gysten 
developed  in  the  Seventies  known  as 
Heresay-II  [11].  Since  its  development, 
the  blackboard  model  has  been  proven  a 
robust  model  of  problem  solving  on 
Epplications  fTon  ocean  surveillanoe  (HASP) 
to  air  traffic  monitoring  (IKICERD) . 

Ihe  traditional  blEKksoEuxi  axxlel 
ocntaiiiB  three  major  ooeponents  as  ^wwn  in 
Figure  3  [12]: 


Mgara  3.  Bw  ttaditienal  Blackboard 
Aceblbaotnra  [12]. 


(1)  Iha  knowladga  scuroas  -  the  knowledge 
needed  to  solve  the  problem  is  partitioned 
Into  knowladga  yuroes,  which  are  kept 
aeparata  end  indtapendmnt. 

(2)  blackboard  data  atruebire  -  Tha 
problem  solving  ateta  data  are  kmit  in  a 
global  data  stora,  tha  blackboi^L 
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XhcwladEM  aouEceB  Broduoa  dianges  to  the 
blecMBoeaedr  vtaidt  Mad  inrra—nrwny  to  a 
aolutian  to  ttie  pcolailae.  nraaijiunwrlnH  and 
interact  icn  taKa  place  aolaly  tiircug^  ttie 
blackl3oeiBd» 

(3)  aaniapol-  ite  XncwLrija  aagcee  repaid 
to  ctMBiBBa  in  the 

bSStdcbStd.  stKucture  of  tite  oontrol 
is  left  qpen.  It  can  ha  in  the  knowladae 
aouroes,  on  the  hLaddboard,  or  a  aepataca 


vdth  a  particolar  doeain.  The  blacMaoard 
in  the  front  of  the  roon  is  the  blackboard 
structure  of  the  architecture. 


Althouglb  ntatlms  vary, 

knowladge  scuroe  activity  is  usuuly  event 
drivafi.  Each  change  to  the  bLaddaoerd 
oonstitutas  an  aeant  ttiat  in  the  rcenonce 
of  acecific  other  infOKsatlan  on  the 
bLacxboard  can  trigger  one  or  noce 
knawledge  aouroes.  The  control  sechanien 
selects  a  single  knowledge  source  to 
eaeeoute  its  action  on  each  probien-solving 
cycle.  The  oontrol  eechanieei  ney  use  a 
variety  of  cxlteria  such  as  the  credibility 
of  die  knowledge  aource'e  triggering 
infoceation,  tfie  reliability  of  the 
knowledge  source,  or  the  iaportance  of  the 
aolutian  it  would  generate.  Wten  a 
knowladae  source  is  trlggpared,  it  leill 
tepically  produce  new  bladchoard  events. 
Inaae  ewcnts  aey  in  turn  trigger  other 
knowledge  eaurcee  [ll]. 

Blacnoard  cysteea  oonetniet  solutions 
inccenentally.  On  eadi  problen  oolving 
cycle  a  single  knowledge  aoucoe  sMecutes, 
generating  or  nodifying  a  eeeall  nnher  of 
aolutian  eleeeents.  Sons  elaeents  are 
aeandilntl  into  growing  partial  solutions; 
others  may  be  apandonedT.  Ideally,  elanents 
ara  aventueiLly  aeaeabled  into  a  ocBplete 
solution. 

As  an  illustration  of  how  a  bladcboard 
uses  cooperating  knowledgn  sources,  we  can 
coeepare  Its  operation  to  an  aircraft 
aocidBnt  investicntion  board.  Wienever  an 
Air  Itroa  aircraft  crashes,  an 
investigation  is  perfocned  to  detemine  the 
facts  surrounding  dw  case.  After  the 
investigation  is  oosplebe,  a  board  is  held. 
The  boara  oonsists  of  the  board  chainean 
and  specialists  dio  aey  be  able  to  help 
deteneine  the  cause  ot  the  accident  (e.g. , 


previcwBly  disouesed  has  associated 
strengths  and  weakneeses.  Merging  the 
nethoos  in  the  proper  fashion  could  create 
a  systen  that  would  benefit  fcon  the 
strengths  of  each  of  the  Methodologies 
thile  nininizing  their  weaknesses.  It  is 
nnstulated  that  a  such  a  blend  would  result 
in  a  synergristic  effect,  allowing  a  eystem 
to  solve  ErohUBB  that  could  not  be  solved 
by  ary  or  the  individual  reasoning 


detemina  the  oause  or  the  accident  (e.g. ,  original  prob: 
pilot,  navigator,  aircraft  Mechanic) .  Cie  based  on  Uiis 
GhairMsn  lists  the  facte  on  a  blackboard  in  synergistic  el 


ths  fbont  of  ths  rooM.  He  then  aeks  for 
ocBMants  fbOM  the  group. 

If  sfecne  in  the  rooM  has  infocMation 
to  add,  they  raiM  th^  h^.  The 
chairaan  calls  on  ons  of  the  people  with 
their  hand  raised,  and  that  perscn  adds  rww 
inf  crest  ton  (facts  or  hunches)  to  the 
board,  then  retume  to  their  seat.  Based 
on  this  new  infcKMBticn  mots  hands  aay  go 
ig>,  and  sons  oC  Urn  hands  that  ware  up  way 
go  dcMi.  The  chaixparaan  again  selac» 
scMaone.  This  parson  nay  add  naw  fhcts  or 
hunchas,  or  nay  refute  earlisr  hunches  by 
othar  aeahars  of  ths  board.  Ths  saasion 
nnnftnues  vitil  ths  reuse  of  the  aocldant 
is  datamined,  or  ontil  the  groqp  can 
cxnCribufee  no  iMar  inforaatlon. 

The  pwellel  to  a  hlsrtttwiwd  is 
deivlauB.  The  cheizeati  is  ths  ocwtrol 
associated  with  the  blackboard.  The  panel 
naaban  ara  tbs  knowlsdga  aouroes,  sach 


Such  a  ^necgistlc  blend  is  possible  by 
Baking  a  fundanoxtal  Modification  to  the 
blackboard  problen-solving  apprcach.  The 
essence  of  the  acdif  icaticn  is  to  partition 
the  systen  based  on  reasoning  Methodologies 
rather  than  knowledge  nodules.  Indeed,  it 
Bay  be  noce  appropriate  to  partition  the 
^tan  based  on  Methods  of  reasoning, 
consider  a  person  taking  a  (closed  book) 
test.  All  Knowledge  to  be  used  during  the 
test  is  self  contained.  There  is  no  reason 
to  believe  that  the  knowledge  is 
partitioned  into  different  nodules  within 
the  perscn.  However,  the  person  nay  use 
sevml  different  Methods  ctf  reasoning 
about  the  problem.  These  Methods  of 
reasoning  can  be  Modeled  as  "reasoning 
nodules." 

This  amroBCh  will  »~n-tvtyio  » 
synergists  effect  by  allowing  the  iBodules 
to  focus  their  individual  strengths  on  a 
problen.  By  ocxiperating  thrcugb  the 
uaddaoerd  and  posting  partial  solutions,  a 
problem  that  could  not  be  solved  by  ary  of 
the  systess  individually  could  be  solved  by 
the  systen  as  a  whole.  That  is,  one 
reascriing  nodule  could  post  a  partial 
solution  not  obtrdnable  by  any  of  the  other 
Bcdules,  and  while  it  lai^^  not  be  able  to 
generate  the  desired  solution,  one  of  the 
reneining  nodules,  which  was  also  unable  to 
generate  the  desirai  solution  from  the 
original  problem,  migfit  be  able  to  do  so 
based  on  this  new  result.  A  secxxid 
wnergistic  effect  is  expected  from  the 
ability  of  one  reasoning  systen  to  refute 
oonclusions  of  another  reasoning  module.  A 
diagram  of  the  sfynergistic  reasoning  system 
is  chown  in  Figure  4. 


Satellite  Autonony  is  a  suitable 
epplication  for  the  proof  of  cxnoept  of  the 
sis.  Setellite  oontrol  is  a  cospllated, 
tedious,  and  labor  intensive  prooees. 


NetH«  consisting  of  fixed  grouhd-besed 
treclclng  stations,  central  oontrol 
f acUitias,  and  links 

[13,14].  %is  iwtwork  cunently  oontrols 
the  opecatlam  of  maproKiMately  80  on-orbit 
satwltes.  nndicum  are  that  135 
aatellitas  will  ba  cn-ocblt  by  tha  year 
2000,  and  150  will  ba  cn-ortaLo  by  2015. 


betueen  souroe  zuid  target) ,  negative 
mappings  (those  attrilsutes  that  are 
ocnfirned  to  not  oarrespand  between  target 
and  source) ,  and  neutral  mappings  (those 
attributes  vAiose  oarreepcndaioe  has  yet  to 
be  ocnfixmed) .  Ihe  feedback  systan  could 
postulate  a  theoren  that  a  netKial 
attribute  has  a  positive  (or  negative) 
mining.  It  could  thai  use  the  automated 
reasoner  to  prove  or  disprove  the  thecren, 
leading  to  an  increase  in  confidence  in,  or 
denial  of,  our  analogy. 
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The  paper  discuses  the  domain  of  Electrical 
Power  Systems  for  Fmdar  Spacecraft  and  its  effect 
on  the  design  of  -M-based  systems  for  health 
monitoring  and  resource  management.  The  paper 
presents  work  on  Electrical  Power  Systems  (EPS) 
Fault  Handling  and  Resource  Planning.  The  Fault 
Handling  System  relies  on  model-based  reasoning 
techniques  while  the  Resource  Planning  System 
relies  on  case-based  reasoning  techniques.  The 
two  systems  perform  their  functions  in  a 
cooperative  way  and  are  distributed  over  both 
ground-based  ^and  space-based  processing 
elements. 


1  Introduction 


presented,  communications  opportunities  may  be 
infrequent  and  of  short  duration;  an  eclipse  may 
occur  each  orbit;  the  system  is  expected  to  operate 
with  failed  or  degraded  components;  and  short 
term  power  demands  will  exceed  the  nominal 
power  output  of  the  solar  panels. 

The  remaining  sections  of  the  paper  present  an 
overview  of  the  domain  of  radar  spacecraft  and  the 
electrical  power  system  is  described  in  sections  2 
and  3;  Sections  4  and  5  describe  the  Ground 
Segment  and  Spacecraft  Operations;  Section  6 
reviews  the  needs  for  automation  and  spacecraft 
autonomy;  Section  7  presents  an  Artificial 
Intelligence  based  approach  to  planning  and 
diagnostics;  Sections  8,  9  and  10  describe 
previous  developments  and  the  present  status  on 
diagnosis  and  planning  work  and;  the  paper  is 
summarized  with  section  1 1 . 


As  spacecraft  and  space  systems  become  larger 
and  more  complex,  the  demands  on  a  traditionally 
structured  ground-based  operation  to  monitor  and 
control  the  various  subsystems  increase 
dramatically.  The  high  operational  management 
requirements  become  readily  apparent  in  the  radar 
spacecraft  application  domain  discussed.  Canada 
is  building  a  civilian  radar  spacecraft  'Radarsat' 
and  is  participating  in  a  research  and  development 
program  for  an  advanced  military  surveillance 
spacecraft  'Space  Based  Radar*  (SBR). 

The  radar  payload  of  this  class  of  spacecraft 
places  demands  on  the  electrical  power  system 
significar>tly  different  than  those  of  civilian 
communication  relay  spacecraft.  The  Electrical 
Power  System  (EPS)  for  radar  spaceaaft  must 
deal  with  a  highly  inclined  low  earth  orbit  radar 
payload  having  tens  of  thousands  of  RF  transmit  / 
receive  elements  demanding  between  5  and  30  kW 
of  electrical  power  (Eatock  90].  In  the  example 


2  Radar  Spacecraft  Overview 

2.1  Mission  and  Orbit  Mechanics 

The  purpose  of  a  radar  spacecraft  is  to  survey 
predetermined  areas  of  the  earth  as  it  passes  over 
them.  The  major  constraints  on  the  mission  are  the 
orbital  coverage  of  the  earth,  the  payload  and 
housekeeping  energy  requirements,  and  the 
available  energy  on  the  spacecraft.  Inevitably, 
there  will  be  times  when  more  radar  exposures  are 
desired  than  can  be  achieved. 

The  requirements  for  the  selection  of  an  optimal 
orbit  for  a  radar  spacecraft  are  significantly 
different  from  those  for  communications  or 
meteorological  spacecraft.  A  radar  spacecraft  is 
typically  required  to  scan  the  complete  earth  over 
some  period,  while  communications  spacecraft  are 
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typically  geostationary.  In  order  to  map  out  a  large 
percentage  of  the  earth,  the  orbit  plane  of  a  radar 
spacecraft  is  highly  inclined  to  the  earth's 
equatorial  plane.  Retrograde  orbits  (i.e.  inclination 
greater  than  90  degrees)  are  common.  With  any 
inclined  orbit,  the  orbit  plane  precesses  about  the 
earth  at  a  rate  dependent  on;  the  angle  of 
inclination  (decreasing  with  inclination),  the  radius 
and  elipticity  of  the  orbit.  Also,  as  the  spacecraft 
orbits  the  earth,  the  earth  spins  on  its  axis  beneath 
the  spacecraft.  These  factors  define  the  payload 
coverage,  the  frequency  and  duration  of  contact 
possible  (spacecraft  to  ground  stations),  and  the 
frequency  and  duration  of  eclipse  operation. 


2.2  Payload  and  Housekeeping  Energy 
Requirements 

Once  the  orbital  mechanics  have  been  determined 
from  the  mission  requirements,  many  constraints 
defining  the  spacecraft  system,  including  the 
ground  support  and  the  EPS  requirements,  will  be 
fixed.  A  typical  spacecraft  of  this  class  is  the 
Canadian  Radarsat.  In  this  case,  the  following 
preliminary  estimates  apply: 

-  Orbit  altitude;  approximately  800  km, 

-  Orbit  period:  approximately  101  minutes, 

-  Eclipse;  maximum  18  minutes,  73  days  long 
season  centred  on  summer  solstice, 

•  Orbit  is  retrograde;  spacecraft  is  nominally 
passing  in  a  direction  opposite  the  earth’s  spin. 

-  Single  ground  station  contact;  12  minutes 
contact  maximum  (at  5  degrees  elevation  above 
horizon);  typically  3  orbits  of  contact  totalling  29 
minutes  duration  (or  less)  followed  by  4  orbits  of  no 
contact.  Cycle  repeats  twice  every  day. 

Earth  observation  spacecraft  tend  to  be  sun 
synchronous.  That  is  the  spacecraft  orbit  plane  is 
at  a  constant  angle  to  the  sun  vector  at  any  time  of 
the  year  (ignoring  earth  declination).  Most 
spacecraft  of  this  class  have  day-night  orbits  (i.e. 
they  observe  both  sunlit  and  dark  sides  of  the 
earth  in  a  single  orbit).  While  also  sun  synchronous 
the  Radarsat  spacecraft  has  a  dawn-dusk  orbit. 
Space  Based  Radar  is  not  expected  to  be  sun 
synchronous  and  as  a  result  will  experience 
significantly  different  ground  contact  and  eclipse 
characteristics. 

The  factors  that  affect  the  design  of  the  EPS 
include  the  duration  and  frequency  of  eclipse 
operation,  the  power  requirements  and  duty  cycle 
of  the  payload  and  housekeeping  functions,  the 


duration  and  frequency  of  contact  with  ground 
station(s)  and/or  the  requirement  for  relay 
spacecraft.  Contacts  with  a  single  ground  station 
are  infrequent  and  of  short  duration.  Contact  duty 
cycle  can  be  improved  significantly  by  using 
multiple  ground  statbns  or  other  spacecraft  to  relay 
the  signal  to  ground. 


2.3  Spacecraft  Mission  Planning 

Planning  the  spacecraft  mission  will  be  considered 
from  the  payload  requirements  viewpoint.  Following 
the  attainment  of  final  orbit,  the  mission 
requirements  define  areas  of  interest  on  the  earth’s 
surface.  The  radar  image  start  times,  duration  and 
quality  define  the  radar  power  profile  needed  to 
attain  the  images  required.  The  ideal  radar  power 
profile  will  be  translated  to  the  required  EPS  power 
profile.  An  assessment  will  be  made  of  the 
available  electrical  power  to  attain  the  EPS  power 
profile.  If  the  available  power  is  not  sufficient  due 
to  weak  batteries,  solar  eclipse,  component 
failures,  or  other  reasons;  the  mission  plan  will  be 
altered  by  dropping  survey  areas  of  lesser  interest 
on  the  earth’s  surface.  This  is  accomplished 
iteratively  by  ground-based  mission  analysts. 


3  Domain  Description:  Spacecraft  Electrical  Power 
System 

The  Electrical  Power  System  includes  a  prime 
power  source  (solar  panels),  storage  elements  for 
eclipse  operation  (batteries),  power  distribution 
busses,  control  electronics  (charge  controllers, 
discharge  controllers,  power  conditioners)  and 
distribution  equipn  ent  (switches,  relays  and  circuit 
breakers).  The  EPS  provides  power  to  the 
spacecraft  loads  which  have  a  variety  of  power 
profile  characteristics.  Duplication  of  component 
and  the  ability  to  configure  the  power  distribution 
network  is  used  to  provide  a  high  level  of 
operational  capability.  While  the  operational 
capability  is  increased,  the  total  power  available  to 
the  spacecraft  loads  may  be  reduced  when 
components  have  failed  (figure  1). 

The  EPS  must  provide  electrical  power  through  all 
phases  of  operation;  launch,  transfer  orbit  and  final 
orbit.  Typically,  through  launch  and  transfer  orbit 
operation,  the  EPS  must  maintain  only  the  loads 
needed  to  attain  the  final  orbit.  After  launch  and 
the  attainment  of  final  orbit,  the  solar  panels  will  be 
deployed  and  the  various  housekeeping  and 
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payload  functions  will  be  tested.  The  test  and 
verification  process  typically  requires  a  few  weeks 
to  complete. 

Following  attainment  of  the  final  orbit,  the  power 
requirements  of  the  spacecraft  are  met  both  by  the 
soiar  paneis  and  batteries.  During  sunlit  operation, 
the  soiar  panei  power  output  is  used  for  battery 
charging,  housekeeping  and  radar  payload 
requirements.  During  solar  eclipse,  only  batteries 
are  available  to  meet  the  power  requirements  of 
the  spacecraft. 

The  characteristics  of  the  radar  payload 
significantly  affect  the  design  of  the  EPS.  Short 
term  power  surges  required  by  the  payload  must 
be  met  by  either  batteries  or  other  short  term 
storage  elements  (capacitors).  The  power  required 
by  the  radar  during  transmission  may  exceed  the 
solar  panel  capacity  by  up  to  100%.  The  resulting 
duty  cycle  averaged  over  the  orbit  is  on  the  order 
of  50%  [Moody  89].  Design  constraints  may  affect 
this  level  during  eclipse  operation. 

The  secondary  loads  in  the  form  of  Attitude  and 
Orbit  Control,  Telemetry  Tracking  and  Command, 
Thermal  Control,  etc.  are  one  or  two  orders  of 
magnitude  lower  in  power  requirements  than  the 
radar  payload.  The  on/off  time  characteristics  of 
many  of  these  loads  are  similar  to  a  random  or 
stochastic  process.  While  these  loads  are  equally 
important  to  the  payload  in  terms  of  spacecraft 
health  and  effectiveness,  the  demands  in  terms  of 
electrical  power  are  lumped  together  as  a  single 
load  which  can  be  modeled  as  a  stochastic 
process. 


4  Ovenriew  of  Ground  Segment/Data  Acquisition 
System 

In  the  Radarsat  project  the  mission  control  ground 
station  (Ground  Segment)  and  the  radar  image 
data  ground  station  (Data  Acquisition  System)  are 
not  coTocated  and  may  in  fact  be  located  in 
geographically  distant  locations.  The  actions 
performed  are: 

-  The  Ground  Segment  performs  health  monitoring, 
management  and  control  of  the  spacecraft.  This 
includes  attitude  and  orbit  control,  EPS  control, 
radar  payload  control,  control  of  the  recorded 
image  playback  to  the  Data  Acquisition  System  etc. 

-  The  Data  Acquisition  System  is  responsible  for 
receiving  and  the  initial  processing  of  the  radar 
image  data. 


Through  increased  on-board  processing,  portions 
of  each  activity  may  be  completed  on  the 
spacecraft. 

Although  both  Ground  Segment  and  Data 
Acquisition  Systems  are  of  equal  importance,  the 
following  discussion  addresses  the  needs  of  the 
Ground  Segment  only.  As  noted  in  section  2.1, 
contact  with  a  ground  station  (Ground  Segment  or 
Data  Acquisition  System)  will  be  a  maximum  of  12 
minutes  for  an  orbit  where  contact  is  possible. 
During  this  period  the  following  events  will  occur; 

-  The  spacecraft  will  appear  at  the  horizon. 

-  The  ground  station  antenna  must  locate  the 
spacecraft  (typically  accomplished  by  the  time  the 
spacecraft  reaches  a  point  5  degrees  above  the 
horizon). 

-  The  spacecraft  is  tracked  through  its  trajectory  to 
a  point  near  the  opposite  horizon  (5  degrees 
above). 

-  When  contact  has  been  made,  the  spacecraft  will 
transmit  subsystem  sensor  readings  (telemetry) 
indicating  the  status  and  health  of  the  spacecraft. 
(Data  Acquisition  System  will  instead  receive  radar- 
image  data  at  this  point.) 

-  The  Ground  Segment  will  process  portions  of  the 
subsystem  status  and  health  data  and  transmit  a 
command  stream  to  take  corrective  actions  that 
may  be  necessary. 

-  The  Ground  Segment  will  also  transmit  the 
payload  command  stream  (schedule)  that  will  be 
used  to  control  the  radar  system  for  the  next  period 
(typically  24  hours). 

These  last  two  actions  will  likely  be  completed  on 
the  next  orbit  pass  (i.e.  101  minutes  later)  following 
initial  processing  of  the  status  and  health  data. 
Thus  two  consecutive  passes  are  needed  to 
receive  telemetry  and  transmit  the  spacecraft 
command  stream/payload  schedule  to  the 
spacecraft. 

The  Ground  Segment  and  the  Data  Acquisition 
System  both  benefit  from  additional  ground 
stations  and/or  relay  spacecraft.  Contact  periods 
can  be  extended  significantly  with  these  additional 
communications  paths.  The  trade-off  is  the 
required  bandwidth  and  number  of  ground  stations 
versus  the  cost  and  maintenance  of  a  relay 
spacecraft  network. 

It  must  be  recognized  that  the  Data  Acquisition  and 
Ground  Segment  systems  serve  very  different 
requirements.  Here  we  are  concerned  with  the 
health  and  control  of  the  Electrical  Power  System 
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(through  the  Groutxl  Segment).  The  primary 
objective  of  the  spacecraft  is  however  to  provide 
radar  images. 

For  civilian  spacecraft  the  need  to  maintain  a 
continuous  radar-image  data  to  the  ground  is  not 
present.  Delays  on  the  order  of  days  may  not  be 
critical  in  terms  of  the  radar  image  information 
gathered.  As  a  strategic  defense  issue,  the 
availability  to  provide  near  continuous  coverage  is 
more  critical. 


5  Spacecraft  and  Ground  Segment  Operations 

Normal  mission  operations  of  a  radar  spacecraft 
are  as  follows:  on  a  given  orbit  the  spacecraft  can 
be  expected  to  pass  over  an  area  of  interest:  at 
that  time  the  radar  will  be  activated  and  image  data 
will  be  acquired.  As  noted  in  Section  3,  the 
capacity  of  the  solar  panels  is  usually  exceeded 
through  these  times  by  a  significant  level.  The 
reliance  on  batteries  and  other  short  term  storage 
devices  causes  the  management  of  power  storage 
to  be  intricately  tied  into  the  mission  planning 
aspect  of  the  spacecraft  (see  section  2.2). 

Power  Storage  Management  and  Mission  Planning 
operations  are  not  automated  in  an  intelligent 
systems  way  and  require  the  attention  of  a  large 
number  of  subsystem  experts  and  designers 
(Adamovits  1990).  Traditional  ground  control 
techniques  rely  on  subsystem  operations 
personnel,  each  controlling  a  single  subsystem  of 
the  spacecraft.  With  a  polar  orbiting  spacecraft, 
long  periods  of  little  or  no  contact  can  be  followed 
by  short  periods  of  intense  activity.  While  this 
approach  may  be  expected  to  remain  for  some 
time  in  spacecraft  systems,  the  reliance  on 
automation  in  the  ground-based  system  aryj 
autonomy  of  the  space-based  system  is  expected 
to  increase. 

Ground-based  activities  during  normal  operations 
are  biased  toward  mission  planning,  station 
keeping  and  health  monitoring.  Station  keeping 
activities  refers  to  orbit  maintenance:  inclination, 
altitude,  eccentricity  etc.  Health  monitoring 
includes:  detecting  component  degradations  and 
failures,  observing  trends  in  system  and  subsystem 
performance,  etc.  All  the  above  activities  are 
expected  to  be  automated  in  increasing  degrees  in 
future  spacecraft. 


Failure  recovery  through  all  phases  of  operation  is 
usually  accomplished  by  a  minimal  degree  of 
designed-in  overcapacity  and  through  the 
configurable  nature  of  the  system.  During  the 
launch  and  transfer  orbK  operations,  the  spacecraft 
relies  on  battery  power  and  minimal  amount  of 
solar  panel  power.  EPS  faults  in  general  and 
battery  faults  in  particuiar  can  seriously  jeopardize 
the  entire  mission.  Following  deployment  of  the 
solar  panels,  the  EPS  is  more  capable  of  dealing 
with  failures  of  individual  EPS  components. 

The  requirement  for  automation  is  defined  at  many 
levels.  In  many  cases  the  requirement  stems  from 
the  lack  of  communication  opportunities.  In  mrmal 
operation  the  spacecraft  is  expected  to  operate 
unsupervised  for  periods  of  up  to  10  1/2  hours  in 
duration.  Potential  problems  with  the  Ground 
Segment  system  extend  this  time  requirement 
significantly.  A  ‘survivability’  requirement  of  7  to  14 
days  of  no  contact  is  also  required.  During  this 
survival  period  the  spacecraft  is  required  to  deal 
with  health  and  normal  subsystem  management 
issues  through  its  on-board  processing  elements. 


6  Automated  Operations:  Space-Based  vs 
Ground-Based 

Two  fundamental  reasons  to  automate  systems  are 
to  assist  humans  in  handling  complexity  and  to 
achieve  critical  (fast)  time  responses.  /Automation 
of  mission  expertise  is  very  desirable  for  assisting 
humans  in  the  complex  spacecraft  operations 
planning  and  management  as  well  as  in  health 
monitoring.  Fault  detection  and  response  is  an 
obvious  area  where  automation  is  desirable  in 
order  to  achieve  critical  time  responses.  As  noted 
previously  this  is  especially  true  when  contact  is 
infrequent  and  communication  is  short  in  duration. 
In  general,  automation  to  assist  humans  in 
handling  complexity  can  be  a  Ground  Segment 
based  function,  and  automation  to  achieve  critical 
time  responses  should  be  space-based. 

Space-based  automation  is  termed  autonomy  in 
this  paper.  In  this  discussion,  autonomy  does  not 
mean  that  the  system  is  not  controllable  by 
humans,  but  that  it  can  operate  with  some  known 
level  of  capability  in  the  absence  of  supervision  for 
as  long  as  is  necessary  (several  hours  through  to 
several  days).  The  system  can  be  overridden  or 
reconfigured  by  humans.  In  the  present  case,  the 
level  of  interaction  possible  with  Ground  Segment 
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support  systems  is  limited  due  to  infrequent 
telemetry. 

The  factors  that  drive  the  time  response 
requirement  are  safety  concerns  and  mission 
concerns.  Safety  concerns  are  due  to  faults,  i.e. 
their  expected  criticality  or  potential  of  criticality. 
Faults  may  shorten  the  life  of  the  spacecraft  or 
decrease  the  capability  of  the  spacecraft  and 
therefore  must  be  detected,  diagnosed,  and  dealt 
with  quickly. 

Mission  concerns  that  drive  the  time  response 
requirements  are  the  importance  of  obtaining  timely 
data.  Questions  that  must  be  asked  are; 

-  When  is  the  data  needed? 

-  When  is  it  available? 

-  Will  the  same  data  be  available  in  N  orbits? 

-  Can  it  be  relayed  to  earth  before  then? 

-  What  is  an  acceptable  cost  to  obtain  the  data? 

If  the  requirement  for  timely  data  is  high  enough 
the  system  must  be  expected  to  operate  in  the 
presence  of  faults.  On-board  systems  must  be  able 
to  detect,  diagnose,  and  recover  from  faults 
autonomously,  and  we  must  accept  the  risks 
associated  with  this  approach. 

The  telemetry  link  is  the  major  factor  in  determining 
whether  processing  occurs  on-board  or  in  ground 
based  systems.  Relevant  telemetry  link  parameters 
include  bandwidth,  time  delay,  and  availability.  All 
of  these  parameters  may  differ  for  the  uplink  acxf 
the  down-link.  They  will  determine,  for  example, 
whether  or  not  there  is  time  to  perform  fault 
handling  functions  on  the  ground  while  maintaining 
an  acceptable  amount  of  data  gathering. 

White  time  response  is  the  driver  for  autonomy, 
other  factors  oppose  increased  autonomy.  They 
are;  the  prohibitive  costs  of  installing  processing 
capacity  on-board  the  spacecraft  and  the  degree  of 
faith  in  the  capability  of  the  autonomous  systems. 
A  lesser  factor  is  the  level  of  instrumentation 
available  on-board.  To  a  limited  extent  more 
instrumentation  can  translate  into  a  reduced 
requirement  for  on-board  processing  to  detect  and 
isolate  faults.  With  increased  instnjmentation,  mass 
and  overall  system  complexity  concerns  resurface. 

The  goals  of  Increasing  on-board  autonomy  are 
limited  by  the  degree  of  orv-board  computational 
capacity  available.  This  is  due  to  the  fact  that, 
installing  computational  capability  on-board  a 
spacecraft  is  very  expensive  in  terms  of  mass  and 
power  consumption,  in  addition,  the  requirements 


for  radiation  hardening,  space-rated  components, 
and  redundarx:y  greatly  increase  the  mass  and 
power  consumption  of  space-based  computers 
over  equivalent  terrestrial  computers. 

Considerable  reluctance  by  spacecraft  designers 
and  operations  personnel  can  be  expected  for  the 
use  of  embedded  systems  for  higher  level  cognitive 
aspects  of  problem  handling.  To  illustrate, 
terrestrial  expert  systems  for  diagnosis  will  include 
an  Explanation  function,  so  that  the  operator  can 
check  the  computer’s  results  against  his  own 
judgement.  This  scenario  is  not  practical  here.  A 
compromise  is  to  implement  a  system  that 
performs  fault  detection  and  module  level  (rather 
than  component  level)  diagnosis  autonomously, 
and  then  implements  a  predetermined, 
conservative  response.  This  may  leave  the 
spacecraft  partially  operable  or  as  a  minimum  in  a 
’safe’  mode.  At  the  next  available  point  the  data  is 
sent  to  the  ground  for  processing  by  ground 
personnel  and  computers,  analyzed,  and  a 
recovery  plan  is  uploaded. 

A  similar  conservative  approach  can  be  generated 
for  autonotTX>us  replanning.  A  mission  which  is 
uploaded  to  the  spacecraft,  consisting  of  a  series 
of  areas  for  imaging  can  contain  associated 
’’importance"  factors  to  describe  the  importance  of 
each  section  of  data.  The  autonomous  controller, 
in  the  absence  of  supervisory  communications,  can 
determine  whether  or  not  to  attempt  to  obtain  each 
section  of  data  by  its  relative  importance  together 
with  the  predetermined  risk  associated  with  a 
partial  fault  diagnosis. 


7  Artificial  Intelligence  Based  Approach  to  EPS 
Diagnostics  and  Planning 

Previous  works  in  diagnosis  and  planning  are 
being  combined  to  form  a  system  that  addresses 
the  Fault  Detection/Diagnosis  and  Resource 
Management  aspects  of  a  radar  spacecraft  EPS. 
Real-time  fault  detection/model  based  diagnosis 
was  explored  in  phase  1  of  the  Health  Monitoring 
Power  Management  and  Control  System  project 
(Section  8).  Case-Based  reasoning  applied  to 
resource  management  was  investigated  in  the 
Case-Based  Planning  System  project. 

The  resulting  system  will  combine  both  model 
based  and  case-based  techniques  to  address  the 
autonomy  and  controllability  requirements  of  the 
EPS.  The  composite  approach  relying  on  both 
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model-based  and  case-based  techniques  was 
taken  in  order  to  provide  a  system  capable  of 
dealing  with  each  of  the  widely  varying  domain 
constraints  described  previousiy. 

In  the  design  described  in  sections  8  and  9,  the 
computational  load  is  distrftxited  between  on-orbit 
(fault  detection/diagnosis  and  replanning)  and 
ground-based  personnel  and  computer  facilities 
(diagnosis  and  planning).  The  system  design  thus 
provides  increased  orvboard  autonomous  fault 
isolation  and  plan  failure  recovery  in  addition  to 
ground-based  logistics  support  in  complex  fault 
diagnosis  and  resource  management. 

In  the  fault  handling  system  presented,  a 
model-based  fault  detection/diagnosis  module  is 
connected  directly  to  the  EPS  sensors  and 
determines  emergerwy  responses  in  real  time.  It  is 
constructed  to  generate  emergency  responses  (i.e. 
before  the  diagnosis  process  is  completed).  This 
capability  is  useful  for  cornplex  faults  where  a 
complete  diagnosis  may  take  a  significant  amount 
of  time  or  may  require  a  probabilistic  analysis.  In 
such  cases,  the  possibility  of  certain  types  of 
dangerous  faults  may  be  indicated  early  in  the 
diagnostic  process,  and  an  emergency  response 
may  be  generated  at  that  time.  The  fault 
detection/diagnosis  system  addresses  a  continuum 
of  faults  from  single  and  multipie  component 
degradations  through  catastrophic  component 
failures.  The  output  of  the  system  is  used  to  isolate 
failed  components  and  to  provide  input  to  an 
adaptive  planner. 

The  planner  and  dynamic  replanner  use  case- 
based  reasoning  techniques  to  create,  revise  and 
maintain  a  case  library  of  successful  operational 
plans.  These  plans  are  continually  updated  as  the 
operational  constraints  of  the  environment  and  the 
EPS  change. 

The  described  approach  to  EPS  Planning  and 
Fault  Handling  has  been  successfully 
demonstrated  on  representative  electrical  power 
circuit  models  and  is  being  extended  to  address 
the  entire  EPS.  The  completed  diagnostic  and 
planning  system  will  be  demonstrated  on  a  large 
scale  sof^are  simulation  and  a  breadboard 
hardware  simulation  of  a  representative  radar 
spacecraft  EPS  [Eatock  90],  [Moody  89]. 


8  Description  of  Health  Monitoring  Power 
Management  and  Control  System  (HMPMCS) 
Phase  1 

In  the  previous  phase  of  the  project,  a 
proof-of-concept  real-time  Power  Usage  Analysis 
and  model-based  Fault  Handling  system  was 
demonstrated  [ISE  89].  For  that  demonstration,  a 
real-time  Power  Usage  Analysis,  Fault  Detection 
ar^  Emergency  Response  system  and  an  off-line 
Fault  Diagnosis  system  were  coupled  to  a 
simulated  spacecraft  EPS.  Power  Usage  Analysis, 
rrxKtel-based  Fault  Detection,  and  Emergency 
Response  generation  were  performed  using  an 
object-oriented  control  system  package  [Zheng 
1989],  while  complete  Fault  Diagnosis  was 
performed  by  an  off-line  system  based  on  a 
commercial  expert  system  shell.  The  control 
system  package  was  also  used  to  generate  the 
EPS  simulation.  Two  computers  connected  by  a 
serial  link  were  used  in  the  demonstration,  one  for 
the  real-time  software  and  the  other  to  run  the 
expert  system  shell  (figure  2). 

A  simple  spacecraft  electrical  power  system  was 
simulated  using  a  real-time  control  system  package 
with  an  update  rate  of  200  Hz.  The  simulation 
included  a  power  distribution  bus  and 
resistive-inductive  loads  controlled  by  switch/circuit 
breakers.  Sensor  and  actuator  faults  were  both 
ea^iy  injected  into  the  simulation.  Single  and 
double  fault  scenarios  were  tested  and  were  used 
by  the  real-time  fault  detection/emergency 
response  system  and  by  the  off-line  fault  diagnosis 
system. 

A  Power  Usage  Analysis  function  was 
implemented.  It  was  based  on  a  schedule  of 
events,  each  of  which  had  an  expected  power 
profile.  The  power  usage  of  the  simulated  EPS  was 
checked  against  the  schedule  on  every  boolean 
command  and  data  event  and  anomalies  were 
detected.  Future  power  usage  and  potential 
hazardous  conditions  were  then  predicted  based 
on  the  schedule  and  the  detected  anomalies. 

A  Model-based  Fault  Detection  and  Emergency 
Response  system  was  also  implemented  on  the 
real-time  system  and  was  mn  at  100  Hz.  It 
monitored  the  sensors  of  the  EPS  and  commands 
for  switch  closures  and  compared  the  expected 
behaviour  with  the  resulting  sensor  readings  from 
the  simulator.  Anomalous  behaviour  was  detected 
and  categorized,  and  emergency  responses  were 
generated  when  necessary. 
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The  Off-line  Fault  Diagnosis  system  was 
implemented  using  an  expert  system  shell  (KEE) 
arid  was  run  on  a  Unix  workstation  (Sun  Sparc  1). 
Simulator  inputs  were  received  over  a  serial  link  at 
1  Hz  and  txjffered  (using  Unix  ppes)  to  the 
application.  A  constraint  propagation  model  was 
implemented  and  linked  to  an  Assumption-based 
Truth  Maintenance  System.  Single  and  double  fault 
analyses  were  demonstrated. 


8.1  Lessons  Learned  and  Future  Development 
Directions  for  the  HMPMCS 

The  phase  1  implementation  of  the  HMPMCS 
system  demonstrated  the  suitability  of  the 
approach  to  spacecraft  EPS  fault  detection  and 
diagnosis.  Specifically,  the  division  of  responst^ity 
between  a  real-time  fault  detection  system  from  the 
more  heuristic  based  diagnostic  system  proved 
successful  in  diagnosing  both  single  and  multiple 
faults.  During  the  project  deveiopment  a  number  of 
lessons  were  learned: 

•  The  real-time  component  using  only  a  shallow 
knowledge  base  often  initiated  ‘safing'  actions 
before  the  off-line  system  could  detect  or  react  to 
its  input  data.  The  data  that  the  off-line  system  was 
operating  on  was  no  longer  relevant  to  the  present 
state  of  the  system.  The  out  of  phase  of  nature  of 
the  operations  may  be  resolved  through  a  meta¬ 
level  reasoning  system  or  other  techniques. 

•  The  reaction  time  of  the  off-line  system  often 
hindered  the  overall  system  performance.  Alternate 
Al  development  tools  and  techniques  will  be 
examined  to  improve  this  components  run  time 
performance. 

-  The  application  circuit  that  was  diagnosed  in 
phase  1  provided  significantly  more  data  than  is 
feasible  for  a  fuH  spacecraft  level  EPS.  This 
simplified  the  design  of  the  HMPMCS  oompor>ents. 
Phase  2  will  require  more  sophisticated  techniques 
to  offset  the  reduction  in  sensors.  This  is  exposed 
to  be  accomplished  through  an  increased  deep 
reasoning. 

Other  upgrades  to  the  Phase  I  work  will  include: 

-  tmplememing  a  more  closely  coupled  fault 
detection  and  diagnosis  system  based  on 
object-oriented  technk^es, 

-  Investigation  of  probabilistic  fault  diagnosis. 

-  Link  fault  diagrwses  to  Power  Usage  Analysis, 

-  More  effort  on  trend  analysis, 

-  Add  planning^replanning  segments,  with  the 
replanning  function  connected  to  fault  handling  and 
trend  analysis. 


-  Connecting  the  system  to  a  large-scale 
breadboard  spacecraft  electricat  power  system 
and, 

-  Identification  of  space  based  and  Ground 
Segment  based  components. 


9  Case-Based  Planning  System 

The  Case-Based  Planning  System  (CBPS)  project 
is  exploring  the  application  of  case-b^ed 
reasoning  techniques  to  spacecraft  electrical  power 
system  resource  planning.  The  approach  has 
foundations  in  the  work  of  Hammond  [Hammond 
89]  and  recent  developments  at  the  Canadian 
Space  Agency  [Ulug  91  a],  [Ulug  91b].  The  CBPS 
relies  on  both  space-based  and  Ground  Segment- 
based  processing  and  case  library  storage 
elements.  The  CBPS  performs  plan  selection, 
revision,  creation,  evaluation  and  dynamic 
replanning.  Many  of  these  are  performed  in  a 
cooperative  way  in  both  space  based  and  ground 
environmerrts  as  described  below. 


9.1  Task  Definition 

The  CBPS  receives  a  list  of  requirements  for  a  set 
period  of  the  mission  in  terms  of  individuai  task 
powerAime  requirements  aixf  task  to  task 
interrelation  constraints.  For  example: 

a)  Turn  on  radar  transmitter/receiver  to  scan  the 
earth  at  orbit  locations  corresponding  to  time 
21.36:19  through  21:43:22;  21:54:45  through 
22:01 :30. 

b)  Recharge  batteries  prior  to  eclipse. 

c)  Prepare  for  orbit  correction:  turn  on  throster 
heaters. 

d)  Perform  orbit  correction:  at  specific  time  turn  on 
thruster  heaters  then  fire  thrusters,  etc. 

Tasks  can  have  the  following  inter-task  constraints: 

-  Tasks  can  occur  concurrently  (a,  b). 

-  Task  must  follow  another  task  (d  must  follow  c). 

-  Tasks  are  mutually  exclusive  (recharge  batteries 
and  eclipse  operation). 

As  defined  in  the  CBPS,  tasks  use  resources  of 
two  classes: 

-  Depletable  resources  (battery  charge,  hydrazine 
fuel  etc.). 

-  Non-depletable  resources  (solar  panel  power, 
solar  heating  etc.).  The  CBPS  will  handle  multiple 
resources  (now  3)  in  the  plartning  process 
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concurrently  (electrical  power,  reaction  thruster 
luel,  etc.). 

9.2  Ground  Segment  Based  Planning  Ckimponents 

The  GBPS  is  provided  a  list  of  tasks  and  their 
corresponding  constraints  from  the  mission  planner 
(operations  personnel  supporting  Ground  Segment 
activities)  as  identified  above.  Given  these,  the 
ground  segment  based  components  of  the  planner 
(see  figure  3)  performs  the  following  actions: 

-  The  selector  attempts  to  locate  an  appropriate 
plan  from  a  library  of  previously  used  or 
precalculated  cases.  If  an  identical  plan  is  not 
available  but  a  similar  plan  is,  then  this  plan  is 
modified  by  including  additional  tasks  or  removing 
extra  tasks. 

-  If  the  selector  cannot  find  or  modify  an 
appropriate  case,  then  a  planner  is  invoked  to 
create  a  new  unicpje  plan  by  applying  constraint 
satisfaction  techniques  on  the  task  constraints  that 
have  previously  been  provided. 

-  Following  the  selection  of  an  existing  plan  from 
the  library  or  the  generation  of  a  new  plan,  the 
plan  is  verified  against  the  model  of  the  EPS  to 
ensure  its  appropriateness  in  the  given  operational 
environment. 

-  The  plan  is  then  submitted  to  a  plan  executor  (in 
the  ground  segment  based  system  this  is  a 
simulated  spacecraft  EPS). 

-  During  the  simulated  execution,  the  plan  may  fail 
due  to  a  variety  of  reasons:  errors  in  selection 
criteria,  errors  in  plan  creation  or  changed 
operational  characteristics  of  the  components.  If 
this  should  occur  then  a  dynamic  repianner  is 
invoked.  The  repianner  repairs  the  plan  from  the 
point  of  plan  failure  and  forward  in  time.  The 
executor  is  again  invoked  and  the  cycle  continues. 

-  Foliowing  execution,  the  plan  is  evaluated  for  its 
success  in  meeting  the  required  operational 
requirements  of  the  mission.  The  library 
maintenance  system  is  then  invoked  to  record  the 
information  for  later  plan  selection.  (Information 
stored  wfth  the  plan  irx:ludes  the  environmental 
parameters  existing  during  plan  execution  and  the 
success  in  operating  in  this  environment.) 

-  When  an  appropriate  plan  has  been  selected, 
modified  or  created,  this  information  is  transmitted 
to  the  spaceaaft  (at  the  next  available  time)  for 
later  execution  in  orbit.  The  transmitted  information 
may  include:  the  name  of  the  appropriate  plan  (or 
the  location  in  the  space-based  plan  Iferary),  a  list 
of  changes  necessary  for  a  spiled  plan  to  be 
effective  in  the  current  situation,  or  a  complete  plan 
to  be  added  to  the  Hbrary  and  used  later. 


9.3  Space-Based  Planning  Components 

The  space-based  components  of  the  GBPS  are 
invoked  based  on  the  time  schedule  dictated  by 
the  orbit  position  of  the  spacecraft  as  it  passes 
over  areas  of  interest. 

-  Given  the  selection  information  provided  by  the 
ground  system,  the  space-based  selector  retrieves 
a  plan  from  the  library  and  submits  it  to  the 
executor. 

-  The  executor  initiates  the  plan  at  the  appropriate 
time  based  on  the  orbit  position  and  other  factors 
(eclipse,  battery  status  etc.).  Many  plans  may  in 
fact  be  executing  concurrently  at  any  time.  Within 
each  executing  plan,  many  tasks  may  also  be 
executing  at  a  time. 

-  If  the  plan  should  fail,  a  space-based  repianner  is 
invoked  to  dynamically  repair  the  plan  or  at  least 
minimize  the  negative  impact  of  the  failure.  (As  the 
recovery  is  required  in  real  time,  the  space-based 
repianner  is  biased  toward  safeing  operations 
rather  than  searching  for  optimal  solutions.) 

-  As  with  the  ground  segment-based  system,  the 
plan  is  then  evaluated  to  identify  Ks  level  of 
success  in  meeting  the  required  mission  goals. 
This  information  is  transmitted  to  the  ground 
segment-based  system  through  the  down-link.  The 
ground  segment-based  system  is  responsbie  for 
library  maintenance  on  both  the  ground  segmbnt- 
based  and  space-based  components  of  the  GBPS. 


9.4  Lessons  Learned  and  Future  Development 
Directions  for  the  GBPS 

The  Gase-Based  Ranning  System  has  been 
implemented  and  tested  against  a  software 
simulated  spacecraft  EPS.  In  its  present  form,  the 
GBPS  perfonos  all  operations  identified  above  for 
the  ground  segment;  space-based  components 
have  not  been  implemented. 

During  previous  phases  of  development  a  number 
of  lessons  were  learned.  Some  of  these  are: 

-  The  GBPS  was  implemented  in  Smalltalk  V/286. 
This  version  of  Smalltalk  has  proven  quite  robust 
and  provides  an  effective  development 
environment  on  which  to  develop  prototype 
systems. 

•  Initial  versions  of  the  planning,  replanning, 
selection  and  evaluation  components  were  coded 
in  a  Smalltalk  compatible  version  of  Prolog.  While 
this  system  was  reasonaUy  well  Integrated  with  the 
SmaUtalr  environment  the  run-time  performance 
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was  not  acceptable.  Alternatives  are  now  being 
examined. 

-  Task  and  plan  definittons  and  library  encoding  of 
the  same  has  been  an  area  of  continued 
development.  This  is  expected  to  remain  for  some 
time  as  more  complex  planners  and  replanners  are 
developed.  As  an  example,  a  complete  redesign 
may  be  necessary  to  support  hierarchical  planning. 
•  An  autonomous  Ubrary  maintenance  facility  may 
be  needed  to  ‘garbage  collect'  unused  or  seldom 
used  plans.  This  will  become  a  necessity  for 
systems  that  operate  over  the  life  of  a  spacecraft 
(several  years). 

Presently  the  CBPS  is  being  evaluated  to  identify 
the  exp^ed  performance  when  scaled  to  a  fully 
operational  radar  spacecraft  electrical  power 
system.  If  the  evaluation  presently  underway  is 
successful,  the  CBPS  will  be  further  developed  and 
integrated  with  the  HMPMCS  providing  the 
planning  component.  Initial  results  look  promising. 


10  Present  Status  of  HMPMCS 

An  integrated  Fault  Handling/Planning  system  is 
being  implemented  and  will  be  connected  to  a 
large  scale  breadboard  EPS  for  Space  Based 
Radar.  The  resulting  system  will  demonstrate 
autonomous  power  management  for  the  SBR  EPS. 
The  system  will  include  both  space-based  and 
ground  segment-based  components. 

The  Health  Monitoring  Power  Management  Control 
System  (HMPMCS)  will  form  the  basis  of  this  new 
system.  The  Case  Based  Planning  System  will  be 
integrated  into  the  HMPMCS  providing  the  planning 
elements.  The  resulting  system  will  draw  from  the 
designs  described  in  sections  8  and  9.  The  two 
systems  will  work  cooperatively  on  the 
diagnosis/planning  aspects  of  spacecraft  electrical 
power  sy^em  management  and  control  and  will 
share  a  number  of  components  (EPS  rrxxlel,  user 
interface  and  reasoning  mechanisms).  The 
identification  of  component  failures  by  the 
diagnostic  system  will  assist  the  planning  system  in 
the  plan  selection  and  evaluation. 

As  noted  above,  phase  2  of  the  HMPMCS  project 
wiH  be  demonstrated  on  a  radar  spacecraft 
electrical  power  system  breadboard.  The 
breadboard  EPS  wiU  demonstrate  advanced 
techniques  in  spacecraft  power  system  design.  The 
EPS  breadboa^  contract  te  in  the  early  stages  of 
phase  2.  The  anticipated  SBR  spacecraft  and  EPS 


recpjirements  are  now  being  defined.  As  the 
diagnosis  and  planning  requirements  are  not  yet 
available,  the  designs  of  the  HMPMCS  and  CBPS 
are  not  yet  fixed. 

Preliminary  designs  indicate  the  system  wifl  be 
similar  to  those  described  in  sections  8  and  9.  It  is 
expected  that  the  real-time  or  near  real-time 
components  will  be  developed  in  another  language 
such  as  C,  C-M-,  or  the  proprietary  C/C++  based 
'Control  System  Probe'  of  ISE  [ISE  1989],  [Zheng 
1989].  The  A1  aspects  of  diagnosis  and  planning 
are  expected  to  be  prototyped  using  an  Al 
development  environment  (possibly  based  on 
Smaittalc).  It  is  anticipated  that  portions  of  the  Al 
components  may  need  to  be  rewritten  using  a 
tTx>re  efficient  language  following  a  review  of  the 
resulting  performance.  It  is  anticipated  that  the 
HMPMCS  and  the  CBPS  can  be  tightly  integrated 
sharing  considerable  code  (EPS  model,  user 
interface,  etc.). 


11  Summary 

The  Electrical  Power  System  and  operational 
requirements  of  high-inclination  low-earth-orbit 
radar  spacecraft  were  described.  Given  these 
requirements,  factors  affecting  the  design  of  an 
Artificial  Intelligence  based  fault  detection/diagnosis 
and  resource  management  system  were  descrSied. 
Past  accomplishments  and  current  activities  on  a 
'Health  Monitoring  Power  Management  Controi 
System'  and  a  'Case  Based  Planning  System'  were 
described. 
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Figure  1  Electrical  Power  System  Block  Diagram 


1  Hz  frame  rate 


Figure  2  Health  Monitoring  Power  Management  Control  System  (HMPMCS)  Phase  1 


Figure  3  Case  Based  Planning  System 
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Or.K.Rob«to 
SoOww  Tachnotogy  Oapt 
Britfih  kmotimcm  (IWiy  Airerall)  Ltd. 


PrMlonPR41AX 

UK 


of  a  poaaiMa  fuiura 
wcniKNogy  n  ns 
in  ordar  to  acMoM  tha  oompMi 
ar  aacnfL  Wa  haaa  Ibloiaad  a 
I  of  pratolyping  and  ovafuadon  to  acNava 
flrat  of  twaa  prototypaa,  wMcfi  oxplorad  tie 
ogy  in  tactcal  misiian  planning  in  a  1  vt  muMi- 
BVR  oombat  soanario,  haa  afraapy  boan 
in  tw  AGARO  fonan.  The  aeoond  piatolypa, 
TACAiD,  which  ia  dhcuaaed  in  ihw  documani,  uaaa  an  idantcai 
aoanario  to  aigiim  tw  cooping  of  high  IowbI  hauriate  raaaon- 
ing  wth  oonwanlional  moduiaa  twt  produce  opiimiaad  ataaring 
and  fMng  cuaa,  and  onamy  and  own  kll  probabtitaa  againct 
aeiectod  taigaia.  Oif  aim  waro  to  aaaaaa  tw  vOhw  of  ombad- 

'  TACAID  ia  daiMopad  uaing  tw  tooi^JuSE!  a  blaekboard  baaad 
ayatam  which  potaaaaat  many  of  tw  ganaric  faaturaa  uaad  in 
Ai  namaly; 

ObtactcriantadknowladgarapiaaantBton.' 

T-)  Otiaci  hiararehyj  ^ 

3^  Obiaet  laiatona^' 
ifiy  Fonaaid  producton  rulaa  j 
^  J  Backwaid  chaining  gcala  j' 
i'y  Symboic  Nat  manipulation  j  ^  ivi> 

Khcwladga  aourca  achaduing  f 


In  additon  twra  ia  aiao  tw  facity  tor  Inking  to  'C  ofafact 
moduiaa.  The  afchMacture  of  tw  ayatam  ia  daacrttwd  in  tarma  of 
tw  knowiodga  rapwaantalon  and  tw  planning  machaniam 
which  couplaa  to  tw  conuantonai  algoritima.  tti  avakwlon  aa 
an  “Nitalganr  ayatam  ia  aiao  naviawad  along  wHh  our  Intandad 
Mura  dbadiona  for  AI  awohwmant  in  miaaion  ayatama. 


2  INTBODUCTION 


orw  auch  prototype,  TACAID  (TACtical  AID), 
deuaiepod  in  tw  Software  Technology  Dept  at  BAa,  Wbiton.  It 
ia  a  waoaich  tool  to  axpioro  tw  uae  of  Aitficiai  Inlaligence(AI) 
idaaa  in  MMA'a  and  inuaaligate  tw  potential  benafte  of  oou- 
plng  batwoan  AI  and  more  conventional  moduiaa. 


3  MACHINE  INTELLIGENCE  IN  THE  COCKPIT 

The  need  for  increaaad  automation  on  future  fighter  aircraft  has 
lad  to  a  program  of  work  wfihin  BAa  to  define  tw  complete  mis¬ 
sion  ayWam.  This  work  is  led  by  Systems  Engineering  R&O 
group  at  Warton.  There  are  several  roles  under  considaration ; 

i)  Sattaor  Fusion  -  tw  inlagralion  of  tw  raw  sensor  data 
avalable  from  tw  aircraft;  radar,  RWR,  IRST,  JTIDS  and 
IFF  to  give  a  co-ordinaled  and  dear  picture  of  the  outside 


a)  Situalion  Assessment  -  tw  view  of  tw  outsida  world 
daiivad  from  tw  sensor  hision  process  is  organised  to 
priofWae  twaats,  isolata  duslert  and  specific  aircraft  forma¬ 
tions,  infer  possible  enemy  intent  and  alocata  targets 
amongst  friendly  aircraft. 

i)  Tactical  Planning  -  tw  pilot  must  decide  on  an  appropriate 
tactical  plan  of  action  once  an  understanding  of  tw  situa¬ 
tion  has  been  reaNsed.  This  plan  must  be  IlexMe  enough 
to  account  for  tw  dynamic  nature  of  tw  outside  world  due 
to  new  and  changing  ttraats,  system  faults,  enemy  missile 
firings  at  own  aircrefi  and  unprediclable  enemy  behaviour. 
Cornputer  systems  which  perform  ttis  task,  or  at  least  aid 
in  tw  process,  are  known  as  ’planners''  or  TDA'sf  Tactical 
Decision  Aida). 

hO  Sensor  Management  -  boti  tw  Situation  Assessnrant  md 
TDA  moduiaa  wM  require  feedback  to  tw  sensors  to  dwtale 
twir  optimal  opendon  in  tw  combat  environment.  Modem 
tensors  have  multi-mode  capabilities,  tw  use  of  which  is 
dependent  on  tw  cunent  tactical  situwion.  Control  of 
search  volumes,  search  timet,  mode  of  operation,  and  cue¬ 
ing  of  aensora  to  iluminaw  a  targeL  eitwr  concurrently,  or 
aequentialty,  is  a  complex  task  in  a  modem  environment. 


Tho  next  gorwration  of  fighter  airorafi  wi  preoant  tw  pilot  wMi 
a  hi|^  dagnm  of  infoiwwllon  to  aasanAaia,  and  alacbonic  oquip- 
mant  to  operate  wHNn  tw  cockpit  In  a  combat  situalion  he  wd 
be  rertyiirad  to  baaiprei  radar  siqnala,  passive  radar  detection 
data,  infrarod  data  and  (%|ilal  Cn  data  from  ground  based  or 
airbenw  ayBlsms(jnDS)  in  order  to  form  a  trotical  plan  of 
action.  This  data  may  oflan  ba  boti  condcting  and  uncartain 
which  wM  add  to  tw  proUam.  He  wM  have  at  his  dhpoaal  a 
complsa  anay  of  waaponi  and  ataetonic  counter  measures, 
and  wN  also  have  to  paiform  routine  monMorlng  of  tw  afroraft 
Inelwmanta.  The  need  tar  future  afrorafi  to  edtibil  high  agt^ 
and  nwnoeuvnMfir  mean  twi  tw  plat  wll  have  to  pertarm 
twaa  taeha  wfihout  tw  aid  of  a  ooititat  Thia  wM  pte  tw  pfiot 
under  an  Irttetwe  worWead  in  an  omtironmant  atwre  tw  time 
batsmen  radar  and  visual  cortaol  In  a  oombat  abuaton  Is  a 
mabor  of  mfnulsa  al  supaiaonie  speeds.  The  outooma  of  such 
ongagsmantt  adi  ba  e^  dtotatad  by  tw  elamant  of  surprise 
dua  to  bwdaqualB  aaobafiatan  of  tils  high  data  tow  rata  rotwr 
twn  datanwfrwd  by  afrarafier  weapon  system  aharaatartatica. 


v)  Utiilies  Management  -  AN  of  tw  above  are  dependent  on 
tw  aystem  stakis  of  tw  aircrafi  to  determine  if  a  particular 
action  or  rocommeiKiation  is  feaatale.  The  heaNh  status  of 
tw  engiiw,  hydraulics,  sensor,  navigation,  light  and 
weapons  systems  of  tw  aircraft  wNI  need  monitoring  to 
proiide  tw  boundary  conditions  for  tactical  planning. 

in')  PNot  Interteoe  -  all  tw  relevant  data  must  be  prsaantad  to 
tw  pilot  in  a  compact  unombiguoim  manner.  The  quantity 
of  data  and  tw  imitad  availabi%  of  space  in  tw  modem 
cockpit  nwha  tw  ’Man  Machine  Intarfaoe’f  MMI )  an 
gquiily  Nnpoitant  part  of  the  miaaian  system. 


The  research  initiative  at  BAe  ia  exploring  al  aspects  of  twee 
probIsms.  A  conceptual  archHacture  for  tw  intaraction  of  twae 
rotas  Is  shown  in  figure  1,  it  should  be  noted  twt  in  realty  tiw 
boundartas  between  twm  are  not  so  otaorty  defined.  As  such, 
it  should  be  afreaaed  twt  ties  dogram  does  not  rsfiect  our 
opMpn  pfwoMpny. 


It  amuM  be  ctaoity  arfrmnlagaeua  tar  a  oomputar  ayatam  to  per¬ 
form  some  of  twee  tosks,  radudng  tw  pital  workload  wfihout 
compramlalng  tw  afroratil  agity.  Such  qratoms  are  known  as 
Marion  Monagoment  AMfi  MMA'a)  and  Ms  documant 


BAe  has  long  reaisod  twt  Artificial  IntoBgance  tochnology  has 
a  strong  rota  to  play  in  tiwae  systoma,  since  twy  are  attompting 
to  rsptaco  or  omutots  nwny  of  tw  cognitivo  prooesaae  tiat  tw 
plot  andtar  tw  co-plot  afready  has  to  perform  in  tw  cockpit. 


The  aetent  and  raatoning  piooesces  involved  in  situation 
anaMmant  and  planning  involvo  heuristic  knoMiladge  of  a  sym¬ 
bolic  nabse,  oAan  invol^  data  dtal  has  an  inherant  uncer¬ 
tain^.  Tha  intatfaoe  batsmen  man  and  machine  must  also  pos¬ 
sess  a  high  dagraa  of  briaCganoa.  Beyond  raspondhig  to  the 
plols  raqMMis,  it  must  monitor  the  plots  oonbol  of  the  aironift 
so  it  is  asmie  of  Ns  situation  and  objediws  so  lial  it  can 
organise  and  prioriliae  Motmalion  affeclveiy,  and  present 
lelevant  data  wWwut  prompting.  It  should  bo  stressed  liat  Ai 
wB  not  piotrida  the  total  sohifcn  to  these  probiams  artd  this 
technology  wH  have  to  be  intograM  srilh  conventional  comput¬ 
ing  ischNques.  In  particular  toe  high  level  reasoning  proooMes 
in  tactical  ptanning  and  slualion  assessment  sri  be  based  on 
numerical  algoritoms  that  ganarata  steering  cues,  missle 
escape  zorwa.  Ml  probabiilias  and  light  paranwtars.  Sensor 
and  UiMes  management  wB  also  have  to  inlagrato  vrito  sys¬ 
tems  toat  are  oontroM  and  have  bean  implaniMtad  oonvart- 
ionally.  It  is  Iw  hope  toat  combining  toeaa  tachniquas  wii 
lead  to  a  qrstom  vrito  a  high  dagrea  of  ayrtargy. 

Our  missjon  systems  vrork  programme  spans  toe  toree 
BAe(MAL)  sitos.  The  Systoms  Engineering  RAD  Dept  at  War- 
ton  is  researching  situalion  assesantent  artd  taclieal  planning 
with  numerical  prooasaing  techniques,  Systems  Engining  at 
Brough  ate  teapottsible  (w  toe  UtMea  management,  and  Sys¬ 
tems  Engineering  at  Kingston  ate  researching  sensor  manage¬ 
ment  and  ploVmachina  intartaoes.  The  SoftvMre  Technology 
departiiant  at  BAs,  Watton  has  baen  tespottstole  for  toe 
research  of  AI  in  mission  tystoms.  It  has  cortoenlratad  its 
efforts  on  Taclieal  Oedaion  Aids  through  toe  development  and 
evelualion  of  prototype  systems.  The  first  of  these  prototypes, 
KATS,  has  already  been  reported  in  a  previous  AGARO 
foru^l].  It  is  a  taweiedge  based  system  vrritian  in  POP-11, 
design^  to  psoMda  taclieal  recommendations  in  a  one  vs.  mul¬ 
tiple  air-to-air  BVRfBayond  Visual  Ranga)  combat  scenario. 
The  system  is  intarfMad  to  a  conventional  simulator,  which  pro- 
vkfoe  a  modal  of  onamy  aircraft  capable  of  performing  aggres¬ 
sive  tactics  on  a  singla  airccaft  controlad  from  toa  knowl^e 
based  system. 

The  second  prototype,  TACAIO,  is  described  in  this  document 
Its  maior  aim  was  to  evaluate  toe  synergistic  coupling  that 
could  be  acMavad  betsrean  AI  modulae  and  tire  conventional 
modulas  already  under  davetopmant  by  toe  Systems  Engineer¬ 
ing  RAO  Dept  at  Warion.  The  system  was  developed  using  tire 
tool  MUSE(2I,  a  general  purpose  software  anviroivnent  for  Ai 
program  dovsfoprnent  The  remaining  part  of  this  document  is 
devoted  to  a  dsKtiption  of  toe  TACAIO  program  and  its  evalua¬ 
tion.  For  a  more  gana^  dfocussion  of  our  mission  systems 
programme  toe  reader  is  referred  to  another  paper  presented 
wHhin  this  foium(3}. 


4  DEVELOPMENT  ENVIRONMENT 

Our  reqMitwnonts  for  a  development  tool  includad  tie  ability  to 
test  our  software  in  an  ambeddad  anvironmant  to  be  fuNy 
wtegralahla  vrito  a  conventional  languaga,  and  possessing  Nl 
toe  ganaric  features  of  an  AI  language  to  $tom  rapid  prototyp¬ 
ing.  A  survey  of  ourrentiy  avalable  tools  fed  us  to  MUSE(2]. 
Muse  is  a  ganarai  purpose  eofeeare  anvironmant  tar  toe 
development  of  AI  appiefejons  in  an  obiaet  orianfed  anviron- 
mant  It  operafee  a  sarfes  of  knowfectae  soutoa  obiaels  which 
communicafe  via  w  sat  of  shared  databaao  obiscls,  vrithki  each 
database  teiovriedge  is  stored  in  toe  form  of  objects.  The 
knowfedge  eouroaa  perform  fnferencing  on  toa  dafebasee  arKf 
return  toeir  reauNe  to  an  appropriafe  database.  The  progrsmmar 
w  ww  mf  uunvui  nv  nuRNNir  ot  iviwwnQQv  90Ufws» 

toe  number  of  dafebasee,  toair  totscaer  m,  and  tiisir  esecution 
schedtiing.  This  ftrpe  of  mechanism  is  often  referred  to  as  a 
NMRIXMra  WCnNMM. 

Tb#  iMiiB  of  IIU8E  ii  Of)  oirioci  ofiontod  moodural  Iomuooo 
caRad  PtSPTALK.  The  language  eiowi  for  tha  creadon  of 
objaefe  toat  hoW  data,  and  fendions  toat  can  oparefe  on  toat 
data.  The  ebiaot  ropresanfe  some  real  or  oonoopluai  ant^  toot 
is  a  ueaftd  vnp  to  vfeualae  a  ptobfem.  The  stuohae  of  an 
obioel  is  hold  in  a  echama,  or  tempfete  daffoWon,  tom  can  be 
mon  omr  ocnonwo  m  •  nMfWiy,  myoev  con  do 


created  dynamically,  relalBd  to  other  objects,  loadad  into  any 
specMsd  database,  and  manipulatsd  in  a  procedural  framework 
of  ists,  maihamalical  operations  and  control  foops. 

The  knowledge  source  objects  can  manipulato  the  knowledge  in 
tire  databesee  eitoor  procedurally  via  Poptak  coda,  or  deciara- 
tivaly,  fay  use  of  Forward  Production  Rules  or  Backward  Chain¬ 
ing  Ru^.  Thair  eMSculion  sequence  is  determinad  by  an 
bfandn  ofajact,  wNch  hokfe  a  prioritised  1st  of  knowledge 
sources  awfeting  execution,  further  objects  can  be  added  to  the 
let  at  a  spectfle  priority.  The  fonvard  production  rulea  exist  as  a 
set  of  nile-set  ol^ects  that  contain  rules  of  toe  form  ; 

IF  oondMion.l  AND  oondkion_2 . THEN  action 

The  eondUono  test  on  the  existence  of  object  instances,  with 
specHic  attifautos,  that  reside  in  one  of  the  blackboard  data¬ 
bases.  The  action  can  consist  of  either,  straight  Poptak  code, 
the  modWeation,  creation  or  delelion  of  an  object  instance  in 
one  of  the  databases,  or  the  action  can  invaka  another 
knowledge  source.  These  rules  are  imptementad  dadaratively 
since  toe  controUng  mechanism  '»  hidden  from  toe  program¬ 
mer,  they  should  be  ihougM  of  as  a  statement  of  foMwIedge  as 
opposed  to  a  Ine  of  code. 

The  Backward  chaining  mechanfem  akrws  the  programmer  to 
impiemeni  an  inferenoe  network  of  goal  states  tiiat  are  depen¬ 
dent  on  a  set  of  sub_goals,  toe  sub_goals  toemselves  can  be 
decomposed  into  titeir  depertdency  on  further  goals.  At  some 
point  tiM  goals  are  directly  related  to  the  existence  of  a  particu¬ 
lar  object,  with  specific  attributes,  in  one  of  the  databases.  Any 
knowl^e  source  can  call  on  the  backward  chaining  system  to 
test  the  logical  state  of  one  of  these  goals  by  performing  a 
depth  first  search  of  the  goal  tree.  The  programmer  is  free  fiom 
worry  about  the  implementation  of  this  controlling  mechanism. 

Given  toe  Ability  of  MUSE  executable  code  to  be  down-loaded 
onto  a  target  processor,  as  would  be  required  for  our  software 
to  nm  embedded  within  a  conventional  system,  and  a  rudHiterv- 
lary  C  interface,  it  meets  most  of  our  requirements.  Despite  its 
wetUlh  of  features  we  have  had  to  perfomr  various  enhance¬ 
ments  to  the  tool  to  fully  meet  our  requirements.  We  have 
enhanced  tire  Musa  tool  to  give  it  ful  compatibility  with  the  C 
programming  language;  object  instance  pointers  can  be  passed 
between  Mim  and  C  to  allow  slot  updates  from  C  and  Poptak 
code  can  be  executed  from  C.  We  have  also  given  the  tool 
enhanced  graphics  capability  for  demonstration  purposes. 


LALGORITHWC  DEYELPPMENT 

Algoritomic  work  on  attack  planning  has  been  carried  out 
rndspendently  from  the  TACAIO  progretmrre.  Given  an  an  air- 
to-air  BVR  scenario,  1  vs  many,  refer^  to  as  the  a  scene,  tire 
algoritirms  perfomi  a  reduced  and  prioritised  sub-set  known  as 
the  p  acerte,  which  are  deemed  to  represent  the  greatest  threat 
to  the  friendly  fighter.  TNs  selection  is  based  on  numerical  data 
such  as  range  rate,  velocity  and  height,  and  therefore  is  better 
suited  to  aigorithmic  computation. 

Given  the  priorilisad  p  scene  list,  algoritoms  exist  that  will  gen¬ 
erate  B^t  lags  against  tire  hostile  aircraft  which  wW  lead  to  the 
destiucion  of  tirese  teigets.  These  flight  legs  are  then 
arutiysed  numericaly  using  simulated  AMRAAM  ^pe  missile 
performance  to  calculate  kil  probaNlities  against  the  targets  for 
missife  firings  along  the  flight  pato.  This  caiouiation  pettoms  the 
kfentical  atrafysis  to  evaluate  erwmy  firing  points  against  self. 
Based  on  boto  calculalions,  the  optimal  firings  points  are 
evaluawd  for  own  akcraft,  with  an  overall  sooie  for  that  option. 
In  ganarai  toe  analysia  results  in  a  set  of  ranked  options  which 
too  ptol  rrtay  opt  to  fly  against  toe  targets.  These  options  ate 
teganarafed  at  each  update  of  toe  sensor  data.  Motedelalson 
toosaa  opiiona  can  be  found  in(4]. 

It  is  racogrtisad  titat  soma  of  these  tasks  may  be  better  suitsd 
to  an  AI  approach  and  our  programme  repteaenis  a  oomprom- 
iae  between,  integraiing  oonvatiifonal  computing  toohniques  into 
toa  cockpit  at  an  aarliar  data  than  amboddad  AI,  and  aNivsIy 
pursuing  AI  teaaarch.  TACAIO's  aim  was  to  placa  a  high  lavol 
houristic  atcNtacture  above  these  algoritoms  to  conbol  if  and 
when  options  should  be  gonarafed,  to  safect  toe  options  for  toe 
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friendly  aircraft  to  fly,  and  to  recommend  allemativa  tirategiea 
whan  it  it  no  longar  safe  to  fly  feesa  options. 


6  TACAID 

TACAID  consists  of  three  main  components.  A  btacHboard 
dafebase  to  hold  an  bttomaf  leprasanlation  of  tiw  world  as  seen 
by  the  afrcraft  sensors.  A  tacM  Knowledge  base,  which  acts 
as  an  kwantoty  of  types  of  engagements,  and  how  arxl  when 
they  should  ootKfectod.  And  a  set  of  reasoning  eferrwnts  that 
monitor  the  stale  of  the  world  and  oonirol  which  plan  should  be 
adopted. 

The  Uackboard  database  consists  of  aircraft  and  missile 
instances,  and  a  special  instance  fer  own  aircrafi  that  is  oort- 
ceptualy  executing  TACAID  in  Ihe  air.  The  state  parametars  of 
Ihm  objects  are  generated  by  a  conventiorwl  simulator,  and 
there  is  a  one  to  one  correspondence  between  the  existanoe  of 
an  object  in  the  TACAID  dtaabase  and  those  generated  by  the 
simulalor.  These  objects  hold  data  that  specif  the  state  of  the 
object! eg.  velocity,  threat  data,  missie  staluselc.),  and  func¬ 
tions  that  act  on  this  data(eg.  missile  firing,  tactical 
manoeuvres,  state  updateelc.). 

The  tactical  database  utilises  tiie  hypothesis  that  the  state 
space  can  be  quantised  into  a  finite,  and  manageable,  set  of 
states  relevant  to  tactical  planning.  Given  that  the  world  is  in 
one  of  these  states  there  witi  be  a  desired  plw,  or  ot^jec^, 
that  wM  be  appropriate  for  tNs  state.  At  run  time,  a  complete 
sat  of  plan  templates  are  defined  to  cover  this  state  space.  A 
set  of  pre-conditions  associated  with  each  plan  dfotate  which 
part  of  the  state  space  apptes  to  this  particular  plan,  aixl  a  set 
of  triggers  dfotate  when  the  aircrafi  state  is  no  lortger  valid  for 
the  plw. 

Within  each  plan  the  state  space  is  quantised  further  to  alow  a 
decomposition  of  the  plan,  or  objective.  This  is  achieved  by  a 
set  of  steps  which  must  be  completed  in  sequence  to  realise 
the  objective.  Steps,  themselves,  are  represented  as  objects 
arrd  hold  pre-cor^tions  and  triggers,  identical  in  structure  to 
those  of  plan  obj^,  which  conbol  the  sequencing  between 
steps.  Pie-cortditions  and  triggers  are  implemented  in  a 
dedarativs  bacKward  chaining  network  as  a  series  of  goals. 
Each  goal  can  be  tiwught  of  as  one  of  ttte  quantised  states  of 
the  world.  The  backward  chaining  mechanism  of  MUSE  will 
evaluate  the  logical  state  of  this  goal,  on  request. 

There  are  four  main  reasoning  modules  within  TACAID.  An 
information  manager:  which  controls  the  flow  of  data  between 
the  oonventkxtel  simutator  and  TACAID,  and  updates,  creates 
or  destroys  the  objects  in  the  TACAID  blackboard  database  as 
necessary.  Any  recommerKlations  for  own  aircraft,  derived  from 
TACAID's  reasoning  logic,  are  communicated  to  the  simulation. 
The  information  manager  also  invokes  a  set  of  forward  produc¬ 
tion  nile-sets  that  perform  some  preliminary  quantisation  of  ttte 
state  space. 

There  is  an  Anahrsw  which  performs  initial  grouping  of  targets 
into  specific  formations.  This  reasoning  module  can  be  tttought 
of  as  performing  situation  assessment  tasks. 

There  is  a  Monitor  reasoning  object  which  searches  ttte  state 
spm  for  world  states  that  are  of  interest  to  the  current  plan. 
This  corresponds  to  avalualing  ttte  triggers  tttat  are  associatad 
with  the  current  plan.  If  any  of  ttiase  triggers  evtauata  true  then 
the  Planner  reasoning  module  is  invoked. 

The  planner  is  invoked  to  cause  aittiar  a  replanning  action,  or 
to  cause  ttte  plannar  to  aiteanoa  to  the  next  stage  of  ttte  plan 
ie.  execute  ttte  next  step  object  assodeted  with  ttte  plan.  The 
brpe  of  action  is  dfotatad  by  the  conespondng  tilg^  which 
imtoked  the  plannar.  Again,  ttte  backward  chaWng  mechanism 
is  invoked  to  search  ttte  pra-condMion  sMs  space  of  oHhor,  the 
plans  held  In  ttte  TACAID  itetsbais(  in  ttte  ease  of  a  re-ptanning 
insttuctton),  or  ttte  stape  essodtaed  wittt  ttte  ounant  pl^in  ttte 
case  ofa  next  slap  btattuetton).  This  process  lasults  in  a  new 
sat  of  lacontmendMlona  for  oiwt  aircrafi  which  are  loadad  into 
ttta  kttormallon  martagar. 


Rgure  2  depicts  the  interaction  of  these  reasonirtg  modules  wMt 
ttte  biacfcboard  database.  The  analyser  has  been  omHtod  for 
darily  sinoe  it  is  only  executed  once  durirtg  run  time  initiation. 
The  heavy  set  arrows  dertote  intaracifon  with  the  database 
whtist  the  smaller  arrows  represent  data  flow,  or  message  pass¬ 
ing  between  objects.  The  blackboard  databMe  can  be  thought 
of  as  being  partionad  into  subsets.  The  nformation  manager 
takas  data  from  the  simulation  and  creates  an  object  represen¬ 
tation  of  ttiis  data  in  the  blackboard.  The  forw^  production 
rule-sets  of  the  infoitiiation  manager  then  analyse  this  data  to 
quantise  ttte  state  space  and  store  their  results  on  ttte  black¬ 
board.  Tha  mformation  rrtanager  then  executes  the  monitor. 
The  monitor  then  searches  through  the  state  space  to  look  for 
evertls  that  are  of  interest  to  ttte  current  plan.  If  such  an  event 
occurs,  ttte  ntonitor  executes  tha  pimner.  The  planner 
searches  ttte  tactical  database  to  generate  an  appropriate 
resportsa.  This  wM  ktvolve  either  ch^ing  or  mocifyirtg  ttte 
currently  adopted  plan,  artd  irtforming  the  monitor  what  is  now 
of  interest  in  the  outside  world.  The  cycle  repeats  itself,  after 
ttte  simulation  updates  itself. 


7  RUN-TIME  BEHAVIOUR 

TACAID  has  been  iitfolemanted  on  a  SUN-3/160  colour  graph¬ 
ics  workstation.  The  layout  of  the  dwplay  is  shown  in  figure  3. 
On  ttte  top  right  is  a  graphics  display  depicting  ttte  current  state 
of  a  simulated  battia.  The  hexagons  represent  enemy  fighters 
and  ttte  squares  represent  enemy  bombers.  To  each  aircraft  is 
attached  a  state  vector  showing  the  ditaction  of  motion,  ttte 
length  of  this  vector  is  proportionai  to  ttte  aircraft  speed. 
TACAID  is  generating  instructions  for  the  aircraft  at  the  centre 
of  the  range  dwpisy,  own  aircraft  The  battia  is  viewed  from  a 
reference  plane  lix^  with  respect  to  own  aircraft  motion.  The 
citcuiar  arfo  ellipsoidal  regions  represent  SAM(  Surface  to  Air 
Missile)  site  zones.  It  should  be  noted  that  these  graphics 
were  developad  by  the  Systems  Engineering  R&D  group  at 
Warton  as  part  of  their  MMA  programme. 

On  the  top  left  is  a  mouse  activated  control  panel  which  alows 
partial  control  of  the  TACAID  process.  This  panel  also  serves 
as  a  display  for  significant  state  parameters  of  own  aircraft  and 
the  world. 

On  the  lower  right  is  another  graphics  window  depicting  the 
current  plan  selected  for  own  aircraft  by  the  TACAID  process. 
This  is  displayed  in  a  hierarchical  format  of  the  selected  plan 
object  and  its  associated  sl^  objects.  Note  that  each  step  has 
an  associated  set  of  instructions  that  will  invoke  the  algorithmic 
modules. 

Rnaly,  on  the  lower  left  is  the  Poptalk  interaction  window,  to 
which,  run-time  mess^es  are  scrolled.  The  user  can  tem¬ 
porarily  halt  the  execution  of  the  process  from  this  window  and 
iitterrogate  blackboard  database,  change  object  slots,  or  re¬ 
direct  the  planning  process  as  he  sees  Ift. 

In  this  particular  example,  TACAID  is  performing  aggressive 
manoeuvring  on  the  escorted  attack  raid.  These  manoeuvres 
are  generated  by  the  algorithmic  modules  as  described  in  sec¬ 
tion  5.  The  TACAID  lo^  searches  ttuough  the  options  data¬ 
base  at  each  simulation  update  to  select  an  optimal  response  to 
ttte  tactical  situation.  At  the  same  time  TACAiD  monitors  the 
state  space  to  ensure  that  aggression  is  the  required  response. 
The  option  selected  is  dwplayed  on  the  graphics  display  along 
vwth  the  optimised  firing  points  against  the  enemy  targets. 

In  ttss  situation,  a  pilot  would  focus  his  attention  on  specific 
states  of  the  outakte  world  tttat  ntay  require  a  deviation  frm  his 
currertt  plan  or  objective.  Por  exampla,  a  missile  firing  by  one 
of  the  targets  at  own  aircraft,  may  represent  such  a  state.  In 
TACAID  this  process  is  modeled  by  the  trigger  objects  associ¬ 
atad  wittt  ttte  plan  and  ttta  stape.  Given  such  a  stale,  a  plot 
would  ttten  perform  a  deeper  reasonirtg  process  based  on  his 
knowledge  of  ttte  existanoe  of  a  missie.  ’How  dattgerous  is 
it?*,  ’Hew  lortg  before  I  must  taka  action  agaktsi  it?’,  "Can  I  stil 
behave  aggressivaly,  and  how?’  etc.  In  just  such  ^  situation 
TACAID  would  be  triggered  to  select  a  now  plan  of  action  and 
ttte  rttortitor  conftgursd  to  evaluato  ttte  threat  of  the  ktoomktg 
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missle.  AggreMiw  irauMeuviing  would  continue  by  selecting 
an  appropriate  attacking  Mght  ftom  tie  options  database 
wHNn  the  constraints  inipoaed  t^  tw  missle. 

The  synergy  we  have  achieusd  between  tie  oouping  of  Al  and 
algorithmic  modules  is  dearly  seen  in  tiese  examplw.  Al  pro¬ 
vides  tie  haufistc  guidanoe  of  what  response  to  make  in  a 
given  situation  and  the  algoiitimic  modules  provide  optmisaiion 
of  tiie  response. 


8  EyALgATlQHANP.AS§ESSMENT 

We  have  developed  a  system  that  has  demonstrated  the  feaai- 
biNiy  of  automated  tactics  in  tie  cockpit  and  tie  advantages  tiat 
can  be  gained  from  tie  synergistc  coupling  of  Al  arid  aigo- 
ritvnic  modules.  This  has  been  achieved  witi  tw  aid  of  an 
enhanced  version  of  tw  MUSE  tod  which  has  proved  to  be  an 


excelent  prototyping  environment  for  these  studws. 

Despite  our  entuisiasm,  we  do  not  believe  we  have  in  any  way 
developed  a  system  twl  codd  ou»pufom  a  pilot  Altiough  pro- 
wdng  a  weak  model  of  tw  pdors  cognitive  tiought  processes  it 
does  iack  valuable  features.  At  present,  TACAJO  is  incapable  of 
deaN^  witi  unoertdnhf  or  performing  predictive  behaviour.  Nor 
can  it  co-ordbiate  its  act^  witi  otwr  friendly  aircraft  in  tw 
combat  scerw.  These  problems  may  well  prove  to  be  too  com¬ 
plex  and  demandng  for  sequentd  computing  techniques  and 
tw  present  TACAID  atdiilscture.  In  aniidpation  of  twse  prob¬ 
lems,  tw  Software  Technology  Dept  at  Warton  has  entered 
kilo  an  academic  and  kidustriai  colaboration  to  develop  a 
mettiodology  for  dstibuted  Al  ardiitaclures(5].  Ahhough  tw 
aims  of  tiis  project  are  non-miltary,  its  results  wM  be  of  great 
benefit  to  our  MMA  programme. 
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ENGINE  HYDRAULICS  WEAPONS  FUEL  FLIGHT 


Figure  1 .  Possible  functionai  architecture  for  a  MMA 
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This  paper  introduces  the  CounterMeasure 
Association  Technique  (CMAT)  that  provides 
automated  threat  response  recommendation 
well  suited  to  handle  Incomplete  and  cor¬ 
rupt  threat  identifications.  By  monitoring 
the  processed  intercepts  and  detections 
from  the  avionics,  countermeasure  reactions 
are  selected  and  scheduled.  By  considering 
all  potential  threat  systems  represented  by 
signal  intercepts,  and  determining  whether 
an  antiaircraft  missile  is  on  the  way,  the 
CMAT  procedure  selects  a  response  to  maxi¬ 
mize  survival  prospects  considering  this 
and  possible  future  threats  to  ownshlp, 
mission  constraints,  and  aircraft  status. 
Countermeasure  selection  maximizes  the 
estimated  frequency  of  survival  without  re¬ 
quiring  a  threat  identification.  The 
entire  database  of  li)cely  threat  systems  is 
considered  in  the  reaction  selection. 


This  paper  discusses  ttfe  CounterMeasure 
Association  Technique  ICMAT)  system  devel¬ 
oped  for  the  Air  Force  ,  which  is  used  to 
automatically  recommend  countermeasure  and 
maneuver  response  to  a  pilot  while  he  is 
under  missile  attack.  The  overall  system 
is  discussed,  as  well  as  several  key  tech¬ 
nical  components.  These  components  Include 
use  of  fuzzy  sets  to  specify  data  uncer-  _ 
tainty,  use  of  mimic  nets^  to  train  the  V 
CMAT  algorithm  to  make  the  same  resource 
optimization  tradeoffs  as  made  in  a  data¬ 
base  of  library  of  training  scenarios,  and 
use  of  several  data  compression  techniques 
to  store  the  countermeasure  effectiveness 
database. 


With  the  growing  sophistication  of  avionics 
and  antiaircraft  systems,  the  workload  and 
complexity  of  tasks  a  pilot  is  required  to 
perform  has  Increased  to  the  point  that 
aids  are  needed  to  satisfy  military  air¬ 
craft  survival  and  kill  goals.  It  is  wide¬ 
ly  recognized  that  automated  assistance  is 
required  to  achieve  the  timely  awareness 
that  permits  tlie  proper  survival  or  offen¬ 
sive  reaction  to  threat  systems,  particu¬ 
larly  in  situations  where  hostile  systems 
have  numerical  superiority.  It  is  also 
necessary  that  these  automations  accommo¬ 
date  sensor  errors  and  intelligence  uncer¬ 
tainty,  including  the  tactic  of  HArtime 
Reserve  Mode  (WARM)  threats  whose  charac¬ 
teristics  way  differ  from  those  of  cata¬ 
loged  pcacetlsie  modes. 
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Force  Base  (ASD/XRS) . 
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Research  Corporation,  Feb  1991. 
Submitted  for  publication. 


This  paper  presents  an  overview  of  the  CMAT 
algorit)im,  the  system  architecture,  as  well 
as  several  useful  artificial  intelligence 
techniques  used  to  manage  data  uncertainty, 
to  solve  and  efficiently  retrieve  required 
data,  and  to  achieve  automated  learning  of 
mission  resource  optimization. 

In  section  3  we  discuss  the  important  is¬ 
sues  which  Influenced  our  system  design. 

In  section  4  we  provide  a  brief  description 
of  the  four  system  modules:  the  sensor  post 
processor,  the  chalkboard  memory  manager, 
the  CMAT  survivability  estimation  module, 
and  the  resource  optimization  module.  We 
also  discuss  the  database  requirements  and 
show  several  Interfaces  that  have  been  de¬ 
veloped  to  enable  data  entry  into  the  de¬ 
veloped  system.  In  section  S  we  discuss 
the  natural  language  Interface  and 
underlying  fuzzy  set  data  representation 
used  to  specify  and  manage  data  uncertain¬ 
ty.  Several  examples  are  Included  which 
show  how  we  perform  fuzzy  data  fusion  of 
datasets  stored  in  chalkboard  memory.  In 
section  6  we  discuss  two  methods  used  to 
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achieve  data  compression  of  the  countermea¬ 
sure  effectiveness  information  databases 
required  by  the  system.  In  section  1  we 
discuss  the  mimic  net  technique  as  applied 
to  the  problem  of  training  our  system  to 
learn  the  proper  optimization  of  counter¬ 
measure  and  maneuver  response  selection  ac¬ 
cording  to  training  libraries. 

2^ _ SYaLaiii..Bs8ign  Issues 

We  identified  eight  critical  issues  in  the 
design  of  a  countermeasure  recommendation 
and  threat  identification  pilot-aiding  au¬ 
tomation.  The  eight  issues  are:  adaptabil¬ 
ity,  uncertainty  handling,  data  compres¬ 
sion,  clear  user  interfaces,  data  buffer¬ 
ing,  efficient  search  of  data  structures, 
chalkboard  memory  architecture,  and  pro¬ 
cessing  speed. 

1.  Since  tactics  and  deployments  can 
change  rapidly,  the  system  design  should 
rapidly  accommodate  change  in  the  database. 
Threat  descriptions,  effectiveness  data, 
sensor  capabilities,  threat  densities,  and 
mission  objectives  change  on  a  regular 
basis.  (For  example,  the  Intelligence  com¬ 
munity  will  obtain  new  information,  threat 
system  capabilities  will  be  upgraded  thus 
nullifying  effectiveness  tables,  defensive 
and  offensive  strategies  will  be  modified, 
and  the  theater  of  operations  may  change.) 
These  changes  should  not  require  recoding 
of  the  system  software.  A  system  with  pro¬ 
longed  utility  must  accommodate  an  environ¬ 
ment  of  constantly  changing  information. 

2.  The  system  should  accommodate  data  un¬ 
certainty.  In  radar  dense  environments, 
pulse  collisions  and  processor  loading  make 
the  extraction  of  clean  threat  signatures, 
(for  example.  Radar  Frequency  (RF) ,  Pulse 
Width  (PW),  Pulse  Repetition  Frequency 
(PRF),  and  Group  Repetition  Interval  (GRI)) 
difficult.  Incorrect  and  Incomplete  data 
may  be  the  only  information  initially 
available  for  threat  reaction.  Future 
systems  may  also  automatically  allocate  and 
direct  the  aircraft  sensor  suite  to  improve 
the  data  detected  in  the  initial  inter¬ 
cepts.  The  threat  reaction  system  must  be 
capable  of  effectively  dealing  with  this 
uncertain  and  Incosqilete  data,  and  of  in¬ 
corporating  improved  data  as  it  subsequent¬ 
ly  becosMS  available. 

3 .  The  system  should  use  data  compression 
techniques.  The  importance  of  this  issue 
becosws  evident  when  one  considers  the 


quantities  of  data  that  are  needed  by  the 
system.  For  example,  threat  response  ef¬ 
fectiveness  depends  on  the  threat,  counter¬ 
measure,  maneuver,  time-to-go,  launch 
range,  azimuth,  elevation,  aircraft 
velocity,  and  aircraft  signature.  Using 
even  a  modest  sampling  of  the  variables 
listed  above  results  in  greater  than  ten 
billion  data  samples  needing  more  than  80 
Gigabytes  of  storage  (at  8  bit  precision) . 
When  compounded  by  the  other  memory  re¬ 
quirements  (inner  and  outer  launch  enve¬ 
lopes,  threat  signatures,  uncertainty  pro¬ 
files,  danger  maps,  mission  objective  ta¬ 
bles),  it  is  evident  the  size  of  the  data¬ 
base  would  be  enormous  without  use  of  data 
compression. 

4.  The  system  should  have  a  user  friendly 
database  interface.  A  graphical  data  dis¬ 
play  presents  the  database  in  a  simple  for¬ 
mat,  which  can  be  easily  edited  by  users 
without  the  need  for  specialized  training. 
For  example,  to  present  effectiveness  data, 
uncertainty  profiles,  launch  envelopes,  or 
danger  maps,  editable  contours  are  used 
rather  than  editak le  table  displays. 

5.  The  system  requires  a  buffer  manager 
to  manage  received  datasets.  This  is  nec¬ 
essary  to  permit  the  threat  response  system 
and  tl.e  sensor  systems  to  operate  at  dif¬ 
ferent  data  rates.  The  buffer  performs 
dataset  memory  management  tasks  which  in¬ 
clude  making  data  fusion  decisions  as  data¬ 
sets  arrive. 

6.  All  memory  management  functions  used 
by  the  buffer  manager  and  by  the  internal 
system  need  to  use  efficient  search  strate¬ 
gies  for  processing  datasets  in  memory. 

This  is  an  important  issue  due  to  the  po¬ 
tentially  thousands  of  datasets  that  may  be 
simultaneously  active  in  memory.  It  is  a 
problem  compounded  by  the  high  number  of 
features  included  in  a  dataset,  which  gen¬ 
erally  also  include  bounds  for  measurement 
uncertainty. 

7.  A  chalkboard  memory  should  be  used  to 
store  the  data  sets  and  other  information 
requited  by  the  system.  By  using  a  chalk¬ 
board,  the  system  can  economize  on  data 
storage  and  processing.  Different  modules 
can  share  interim  calculations  and  results 
as  t>:ey  collectively  process  their  automa¬ 
tion  tasks. 

8.  The  system  must  be  capable  of  running 
In  real  time  In  practical  architectures. 
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Parallel  architectures  permit  system  growth 
without  Increases  In  processing  time. 

_ The  CHAT  System  Design 

A  data  driven  approach  Is  used  to  make  the 
CMAT  system  adaptable  to  different  situa¬ 
tions.  Data  compression  and  fusion 
techniques  are  used  to  manage  the  large 
amount  of  expected  measurement  data.  The 
CMAT  system  uses  quantitative  discrimina¬ 
tion  to  associate  measured  data  with  stored 
data,  but  represents  this  data  In  terms  of 
fuzzy  sets  to  manage  data  uncertainty. 
Finally,  the  system  uses  an  automated 
learning  technique,  the  mimic  net,  to 
provide  recommendation  of  optimal  threat 
response. 

The  CMAT  system  concentrates  on  achieving 
three  functions: 

a.  quality  assessment,  fusion,  and  pro¬ 
cessing  of  the  sensor  data  available 
on  tactical  aircraft. 

b.  recognition  and  priority  assignment 
to  threat  situations  requiring 
response. 

c.  recommendation  of  viable  defensive 
reaction  given  the  threat  situation. 

The  major  functional  components  of  the  CMAT 
procedure  are  explained  in  the  subsections 
below  and  illustrated  in  Figure  1. 


Figmr*  1.  SyetMi  >leak  Olagra*. 

i-J _ Sensor  Post  Processor 

The  sensor  post  processor  stores,  fuses, 
and  sorts  measurement  datasets  collected  by 
onboard  sensor  systems.  The  datasets  are 
grouped  into  two  types:  radar  signature 
data  or  missile  kinematic  data.  Each 
dataset  consists  of  sieasured  feature  values 
and  their  associated  measuresiant  variances. 

Typically,  there  will  be  few.  If  any,  mis¬ 
sile  datasets,  corresponding  to  few 


missiles  in  flight  in  the  battle  area.  In 
contrast,  there  could  be  thousands  of  radar 
signature  datasets,  corresponding  to  all 
active  fire  control  radars  as  well  as  spoof 
emitters,  acquisition  and  tracking  radars, 
and  search  radars.  The  radar  signature 
datasets  enable  threat  Identification  and 
permit  appropriate  threat  response  strate¬ 
gy.  However,  the  radar  signature  datasets 
must  also  be  associated  with  the  missile 
datasets.  This  Is  especially  difficult 
when  angular  resolution  Is  low  and  there 
are  great  numbers  of  distinguishable  radar 
datasets.  The  system  uses  two  data  buff¬ 
ers,  one  for  each  dataset  type. 

The  two  buffers  are  structured  as  2D  binary 
trees  Indexed  on  azimuth  angle  of  arrival 
which  include  upper  and  lower  measurement 
uncertainty  bounds.  The  benefit  of  the 
data  organization  as  a  binary  tree  storage 
lies  in  the  use  of  binary  search  strategies 
to  efficiently  locate  and  sort  datasets 
into  'bins'  .  Efficient  data  structures  are 
a  consideration  since  thousands  of  datasets 
can  be  simultaneously  active. 


As  new  datasets  are  added  to  the  buffers,  a 
Mahalanobis  distance  measure  is  calculated 
between  each  new  dataset  and  the  datasets 
already  contained  in  the  corresponding 
buffer.  The  distance  measure  is  developed 
from  estimated  measurement  variances.  The 
data  is  fused  to  minimize  the  expected 
variance  of  the  combination.  The  variance 
estimates  are  derived  using  sensor  resolu¬ 
tion  and  estimated  signal-to-interference 
ratios  in  information  theoretic  expressions 
for  the  particular  discrimination  proce¬ 
dure.  These  variances  are  corrected  for 
each  estimated  sensor  loading  corruption 
error,  eq  (1) .  Datasets  judged  to  be  sim- 


_  (^■XLood) 
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(1) 


where 

-  Sensor  Resolution 
Load  =  function  of  sensor  loading 
in  pulses  per  second 
•  constant  term  on  order  1-10 
SIR  -  Slgnal-to-Interference-Ratio 


liar  are  fused  Into  a  single  dataset.  This 
not  only  improves  the  quality  of  the 
measurements,  but  helps  reduce  the  number 
of  datasets  to  be  stored.  If  a  dataset  Is 
not  sufficiently  sliBll*T-l:b  an  existing 
dataset,  a  liew  one  Is  created  In  the  appro¬ 
priate  buffer. 
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4?  Chalkboard  Memory 

The  purpose  of  the  challcboard  memory  module 
Is  to  periodically  download  data  from  the 
sensor  postprocessor  and  convert  It  to  a 
format  recognized  by  the  rest  of  the  sys¬ 
tem.  The  significant  feature  of  the  chalk¬ 
board  memory  manager  Is  that  It  centralizes 
data  storage  and  allows  all  system  modules 
to  retrieve  and  update  data.  This  archi¬ 
tecture  not  only  provides  for  efficient 
storage  of  all  measurement  data  In  one 
place,  but  Is  also  flexible  to  permit  fu¬ 
ture  modules  to  be  Integrated  with  minimal 
Interface  difficulty.  The  three  primary 
functions  of  the  chalkboard  memory  module 
are:  data  formatting,  data  fusion,  and 
memory  management. 

Managing  data  uncertainty  Is  a  required 
attribute  of  the  system.  To  achieve  this, 
the  data  from  the  missile  and  radar  signa¬ 
ture  dataset  buffers  Is  formatted  to  be 
compatible  with  fuzzy  set  based  uncertainty 
management  algorithms.  The  datasets  are 
converted  to  a  fuzzy  set  representation,  as 
shown  in  Figure  2.  The  measured  feature 
value  converts  to  the  center  point  while 
the  feature  measurement  variance  converts 
to  a  fuzzy  set  width. 


rigarm  2.  Coawmrtiag  •  M— mrememt 
to  •  r«CBy  Set. 

Two  Chalkboard  Short  Term  Memory  banks 
<CSTM) ,  one  for  missile  data  and  one  for 
signature  data,  are  used.  After  download¬ 
ing  and  formatting  the  datasets  from  the 
sensor  post  processor  data  buffers,  the 
chalkboard  memory  aK>dule  Integrates  the 
newly  formatted  datasets  with  those  already 
in  the  CSTM.  This  Is  accomplished  by  com¬ 
paring  each  newly  forswtted  dataset  to  each 
existing  dataset  In  the  CST>:  using  a  dis¬ 


tance  measure.  This  measure  Includes  a 
fuzzy  set  proximity  test  to  compare  fuzzy 
features  (2)  and  a  Scalar  proximity  measure 
to  test  Scalar  features  (3) .  Datasets  that 
pass  the  distance  measure  criteria  are  de¬ 
clared  distinct  datasets.  The  criteria  are: 

FP(Sii,S|,bn)  >  Threshold  for  all  bn  (2) 

SP(Sk,Si,Un)  >  Threshold  for  oil  Un  (3) 

where 

FP(Sk,S|,bn)*eaXb.ein(0(S|„bn),0(Si,bn») 
SP(SK,S|,Un)-l^*^^^^**^"^  -  U(S|,Un)  I 
<j2(Sk,Un)  ♦  o2(S,,0„> 

S|i  kth  signature  dataset 
S|  >  1th  signature  dataset  from  CSTM 
bn  =  nth  fuzzy  feature 
Un  =  nth  scalar  feature 
V  =  measured  value  for  scalar  feature 
O  =  measured  variance  for  scalar  feature 
FP  “  fuzzy  proximity  measure 
SP  =>  scalar  proximity  measure 
0(S|t,bn)  “  fuzzy  membership  for  nth  feature 
of  kth  observed  signature  dataset 

Scalar  data  are  fused  to  minimize  measure¬ 
ment  variance.  Fuzzy  sets  are  fused  using 
the  fuzzy  fusion  algorithm  discussed  In 
section  5.  After  each  newly  formatted 
dataset  has  been  processed  the  buffers  are 
cleared  to  make  way  for  new  sensor  data. 

As  newly  formatted  datasets  are  fused  with 
datasets  already  In  the  CSTM,  a  reinforce¬ 
ment  coefficient  associated  with  the  fused 
dataset  is  increased.  Conversely,  the 
coefficients  associated  with  datasets  that 
did  not  get  fused  are  decreased.  Thus 
greater  emphasis  is  given  to  datasets  that 
are  seen  repeatedly  In  successive  update 
Intervals.  If  a  particular  dataset's  coef¬ 
ficient  drops  below  a  threshold,  the  data¬ 
set  is  deleted  from  memory,  reflecting  that 
the  particular  measurement  Is  no  longer 
confirmed  by  the  sensor  systems.  The  CSTM 
have  exponential  reinforcement  and  forget¬ 
ting  laws.  The  CSTM  also  stores  data  from 
the  response  option  generator  and  threat 
assessment  and  prioritization  modules  about 
threat  classification  for  use  by  the  rest 
of  the  system. 

_ Strategy  Generator 

The  strategy  generator  procedure  generates 
a  ranked  list  of  appropriate  response  op¬ 
tions  using  the  data  In  short-term  memory. 


In  the  CMAT  procedure,  three  steps  deter¬ 
mine  the  effectiveness  of  the  threat  re¬ 
sponse  options.  Figure  3.  In  the  first 
step,  the  signature  datasets  corresponding 
to  each  detected  threat  are  processed 
through  a  layer  of  threat  neurons.  Each 
threat  neuron  calculates  a  measure  of  simi¬ 
larity  between  the  observed  threat  and  a 
threat  cataloged  in  the  threat  database. 

In  the  second  step,  these  similarity  mea¬ 
surements  are  modified  based  on  the  threat 
density  probabilities  specified  in  the 
threat  map.  In  the  final  step  the  similar¬ 
ity  data  is  processed  through  a  layer  of 
countermeasure  neurons.  Each  countermea¬ 
sure  (CM)  neuron  evaluates  the  effective¬ 
ness  of  a  particular  response  option  based 
on  similarity  information,  engagement 
geometry,  and  the  countermeasure  effective¬ 
ness  data  stored  in  another  database. 


feature  membership  function  of  the  cata¬ 
loged  threat.  For  every  such  pair,  the 
fuzzy  set  intersection  is  computed.  This 
value  is  then  tuned  according  to  a  database 
confidence  factor  and  weighted  by  the  rela¬ 
tive  importance  of  the  particular  feature. 
These  values  are  summed  together  to  form 
one  value,  the  similarity  of  the  observed 
threat  to  the  particular  known  threat  (4) . 

R{Sk,T,)  =  (4) 

Z  OsF(«axb.ein(0(Sk,b„),K(T,..b„)))) 

m  n 

where 

F(x)  =  confidence  tuning  function 

=  a  ♦  (b  +  cx)^ 

On  =  emphasis  weight  for  feature  n 

On  =  emphasis  weight  for  threat  mode  m 

E  On  ■  1 .  So.  >-  1 
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The  similarity  calculation  is  shown  in 
Figure  4.  The  diagram  illustrates  how  the 
system  processes  '  ncertainty  information. 


n  • 

The  strategy  generator  procedure  makes 
reasonable  countermeasure  recommendations 
in  the  case  of  incomplete  or  missing  data. 
For  instance,  consider  a  detected  threat 
which  is  operating  in  a  mode  entirely 
different  from  those  cataloged  in  the 
threat  database.  This  situation  could  re¬ 
sult  in  a  measured  feature  value  that  has 
no  overlap  with  the  fuzzy  set  descriptions 
of  the  corresponding  feature  of  the  threats 
in  the  database.  Figure  5.  To  mitigate 
this  problem,  the  fuzzy  set  corresponding 
to  the  particular  observed  feature  is 
iteratively  broadened  using  a  feature  re¬ 
laxation  procedure  until  some  minimum  over¬ 
lap  is  achieved.  The  similarity  measure 
for  that  feature  is  then  recalculated  and  a 
response  recommendation  is  made  based  on 


this  new  calculation.  This  approach  makes 
a  recommendation  based  on  a  closest  match 
between  observed  threat  and  known  threats. 


Each  faatura'9  fuzzy  sat  Is  sldsned  until 
a  alnlauB  over  I  op  crltspla  Is  reached 


base  variable  (J) 


A  fuzzy  pair  is  fonsed  for  each  feature 
consisting  of;  a)  the  feature  swsibership 
function  of  the  observed  threat,  and  b)  the 
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The  threat  neuron  procedure  has  several  key 
features: 

a)  It  simultaneously  accommodates  sensor 
measurement  uncertainty  and  database 
threat  description  uncertainty  via 
the  use  of  fuzzy  sets. 

b)  It  uses  a  selectable  weight  to 
reflect  variation  In  a  feature's 
relative  discrimination  Importance. 

c)  It  uses  a  parallel  architecture  which 
allows  for  efficient  processing  of 
the  fuzzy  pair  data. 

d)  It  uses  piecewise  analytic  functions 
for  membership  function  representa¬ 
tion  which  allows  for  fast  closed 
form  analytic  solutions  to  the  fuzzy 
Intersection. 

e)  It  Is  data  driven. 

In  the  second  step  of  the  strategy  genera¬ 
tion  procedure,  the  similarity  measurements 
from  the  threat  neurons  are  passed  through 
a  layer  of  proximity  neurons.  Here,  data 
from  the  threat  map  is  used.  This  map  Is 
constructed  using  Intelligence  Information 
and  premission  briefing  data  that  specify 
the  probable  number  and  locations  of  each 
of  the  cataloged  known  threats.  Each  simi¬ 
larity  measure  Is  completed  by  multiplying 
it  with  a  proportional  function  of  the 
threat  probability  estimate.  The  resulting 
similarity  measure  represents  the  proximity 
of  the  observed  dataset  to  the  known 
threats  In  the  database  with  adjustments 
for  data  uncertainty  and  expected  threat 
density  probabilities. 

Figure  6  shows  the  final  step  In  which  the 
similarity  measures  are  passed  through  a 
response  neuron  layer.  The  survivability 
estimate  Is  calculated  by  considering  the 
assessment  of  the  detected  threat  being 
each  of  the  known  threats  In  the  database. 
The  countermeasure  effectiveness  Is  derived 
for  the  engagement  geometry  and  kinematic 
parameters  of  the  engagement.  This  algo¬ 
rithm  has  the  benefit  that  Its  operation 
does  not  depend  on  whether  dissimilar 
signature  datasets  were  fused  together  In 
chalkboard  memory.  This  Is  because  the 
threat  response  algorithm  always  considers 
the  likelihood  that  the  detected  threat  Is 
each  known  threat  when  calculating  surviv¬ 
ability. 

The  survivability  calculation  can  take  ad¬ 
vantage  of  parallel  computing  architectures 
so  that  processing  spaed  la  Independent  of 
the  number  of  response  options.  The  proce¬ 


dure  uses  a  data  driven  approach.  Changes 
In  the  effectiveness  database  are  made 
without  requiring  changes  to  the  response 
neuron  algorithm. 


P(RJ)  •  suruluobi  I  ity  of  jth  Cfl  response 
t  ■  tlae-to-go  r  •  ♦/-  launch  range 

az  •  ♦/-  aziauth  Tn  •  nth  Threat 

el  ■  ♦/-  eleuat Ion 

riguze  6.  Respoase  Meurons 

_ Reaction  Selection 

The  list  of  generated  reaction  strategies, 
ranked  by  estimated  effectiveness.  Is 
processed  by  the  Reaction  Selection  module. 
This  module  makes  the  high  level,  tactical 
tradeoffs  necessary  for  final  strategy 
selection.  Here,  the  CHAT  system  considers 
complex  tradeoffs  (mission,  tactics,  esti¬ 
mated  effectiveness,  and  aircraft  status), 
by  directly  mimicking  off-line  databases  of 
expert  knowledge.  A  library  of  expert 
knowledge  supports  this  function.  The 
mimic  net  technology  used  for  this  applica¬ 
tion  is  discussed  in  section  7. 

_ Databases 

Integral  to  the  CHAT  threat  response  recom¬ 
mendation  system  are  the  databases  contain¬ 
ing  the  descriptions  of  the  known  threat 
systems.  The  first  such  database  contains 
all  features  described  in  terms  of  fuzzy 
sets,  for  example,  radar  frequency,  pulse 
repetition  frequency,  and  pulse  width.  A 
second  contains  descriptions  of  the  threat 
inner  and  outer  launch  envelopes.  The 
launch  envelopes  describe  the  aerodynamic 
performance  of  the  antiaircraft  missile. 

_ Database  Interface 

Database  Interfaces  are  used  to  allow  the 
user  to  quickly  review  the  database  entries 
as  well  as  to  readily  change  or  add  data. 
These  user-friendly  Interfaces  are 
necessary  considering  the  amount  of  data 
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required  by  the  CMAT  system.  The  data  Is 
an  integral  part  of  the  system,  and  only 
Incremental  changes  need  to  be  made  on  a 
regular  basis.  That  is,  there  is  no  need 
for  routine,  voluminous  data  entry. 

Three  interfaces  are  shown  in  Figure  7. 

The  first  of  these  interfaces  is  used  to 
enter  the  fuzzy  feature  descriptions  of  the 
known  threat  systems.  This  tool  allows  an 
analyst  to  express  fuzzy  threat  feature 
values  for  each  known  threat  system  in  each 
known  operating  mode  using  simple  English 
sentences.  A  natural  language  translator 
maps  these  sentences  into  piecewise  contin¬ 
uous  analytic  functions  to  mathematically 
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represent  the  uncertainty  conveyed  by  the 
original  sentence.  The  user  tunes  the 
graphical  descriptions  of  threat  features 
using  the  Interface  to  his  satisfaction. 

The  second  Interface  is  used  to  enter  data 
describing  threat  launch  envelopes. 

Contours  representing  two  dimensional  slic¬ 
es  of  a  three  dimensional  launch  envelope 
contour  are  drawn  on  the  screen  with  a 
mouse.  Models  of  the  user  input  data  are 
saved  rather  than  the  user’s  original  data 
points,  resulting  in  a  significant  savings 
in  storage  requirements. 

Similarly,  the  third  Interface  shown  is 
used  to  enter  the  effectiveness  profiles 
for  all  available  countermeasures  against 
all  known  threat  systems. 

^ _ Linguiatic  Variablea  and  Fuzzy  aeta 

Fuzzy  sets  are  used  to  characterize  data 
uncertainty  in  the  CMAT  database.  For 
example,  threat  feature  information  (PRF, 
PW,  GRI,  RF,  Infrared  (IR)  Color  Ratios) 
are  characterized  using  fuzzy  sets.  The 
natural  language  interface  used  to  specify 
the  fuzzy  memlaership  functions  is  based  on 
the  use  of  linguistic  variables  as  de¬ 
scribed  below. 

Linguistic  variables  are  used  to  efficient¬ 
ly  specify  data  uncertainty  and  provide 
clear  Interfaces  with  a  numerical  database. 
They  differ  from  traditional  variables  in 
that  their  values  can  be  represented  by 
sentences  in  addition  to  numbers.  Figure  8 
shows  a  comparison  of  a  set  of  numerical 
and  verbal  linguistic  values.  Use  of 
English  phrases  to  express  the  value  of  a 
variable  provides  interesting  opportunities 
for  characterizing  data  in  a  way  strictly 
limited  by  numerical  methods.  For  in¬ 
stance,  linguistic  variables  effectively 
describe  qualitative  attributes  or  behav¬ 
ior.  These  qualitative  descriptions  pro- 
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vide  an  effective  method  for  specifying 
data  uncertainty.  Graphical  feedback  rap¬ 
idly  trains  the  user  in  the  use  of  linguis¬ 
tic  modifiers. 

Linguistic  variables  are  useful  because 
they  simplify  specification  of  complicated 
data  sets.  It  is  not  necessary  to  under¬ 
stand  rigorous  Implementation  details  or 
detailed  equations  in  order  to  enter  data. 
The  linguistic  values  are  checked  for 
proper  grammar  then  automatically  translat¬ 
ed  into  piecewise  analytic  functions 
characterizing  the  fuzzy  set  membership. 

Figure  9  shows  a  representation  of  the  lin¬ 
guistic  value  'Near  8  GHz  RF.'  The  value, 
'Near  8  GHz  RF'  is  represented  graphically 
by  a  compatibility  function.  The  compati¬ 
bility  function  (sometimes  referred  to  as  a 
membership  function)  describes  the  degree 
of  compatibility  each  value  of  the  base 
variable,  radar  frequency,  has  with  the 
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linguistic  value,  "Near  8  GHz."  As 
expected,  compatibility  decreases  when  the 
base  variable  is  increased  beyond  8  GHz  or 
decreased  less  than  8  GHz. 

Suppose  a  threat  is  detected  with  a  RF  of  2 
GHz.  Based  on  this  single  threat  feature 
measurement,  when  comparing  the  observed 
threat's  RF  with  a  threat  whose  RF  is  rep¬ 
resented  by  "Near  8  GHz",  it  would  be  con¬ 


cluded  that  no  compatibility  exists  between 
the  two  descriptions.  Conversely,  if  the 
detected  RF  was  equal  to  7.7  GHz,  it  would 
be  concluded  that  there  is  a  high  compati¬ 
bility  between  the  two  descriptions. 

Precise  rules  exist  which  define  how  lin¬ 
guistic  values  are  formulated  and  how  these 
formulations  ate  interpreted.  Therefore, 
although  linguistic  variables  can  be  used 
to  describe  qualitative  attributes,  their 
exists  an  exact  mathematical  formulation 
which  echoes  the  precise  meaning  assigned 
to  each  linguistic  value.  During  program 
execution  the  value  of  each  linguistic 
variable  is  translated  into  a  fuzzy  set  de¬ 
scription.  These  fuzzy  sets  are  described 
by  precise,  piecewise  continuous  analytic 
functions. 

All  linguistic  variables  consist  of  five 
basic  components:  primary  terms,  connec¬ 
tives,  negation,  units,  and  feature  name. 
Words  like  'high',  'low',  and  'moderate' 
are  defined  as  primary  terms.  Each  primary 
term  is  like  an  additional  vocabulary  word. 
The  more  words  their  are,  the  easier  it  is 
to  describe  the  concept  being  presented. 
Generally,  three  to  five  different  primary 
terms  have  been  implemented  for  each  threat 
feature  in  the  CHAT  database.  In  addition, 
any  real  number  can  be  used  as  a  primary 
term.  Table  1  shows  the  vocabulary  of  lin¬ 
guistic  terms  currently  available  in  the 
CMAT  natural  language  interface. 

To  simplify  the  specification  of  a  primary 
term  generic  functions  are  used.  Figure  10 
shows  three  standard  functions  currently 
available  in  the  database.  Use  of  these 
generic  functions  provide  several  advantag¬ 
es  to  program  operation: 


connect lv«a 

{  and,  or  } 

nogot 1  on 

{  not  } 

hodgoo 

(  oxtrooely,  vorg,  neor,  approx lootoly,  oore  or  less, 
grooter,  less,  higher,  lower,  longer,  shorter,  larger, 
saoller,  wider,  norrower,  than,  ouch.  Increase,  decrease  ) 

prlaorg  torao 

(  high,  low,  swoll,  large,  wide,  narrow,  long,  short, 
ooderote,  olddte,  CU,  seeker,  long  track,  short  track, 
ground-based,  oirborne,  cloee  to  ground,  close  to  sky, 
and  real  nueber  ) 

unit  ocoloo 

{  mill,  CentI,  Kilo,  Rega,  Glgo  ) 

unit* 

(  frequency,  tiee,  size,  ratioe  ) 

aodlflMs  ovxxMtly  la  tha 

CHRV  aafearal  laayvaya  latarfaaa  databaaa. 


Tabla  1 
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plaoawlao  aoalytla  aaaborahlp  f uaofcloaa . 


1.  Analytic  functions  (instead  of  data 
samples)  are  used  to  represent  data.  Thus, 
accuracy  and  quic)c  speeds  associated  with 
analytic  computation  methods  are  utilized 
when  computing  with  linguistic  values. 

2.  When  primary  terms  are  described  by  co¬ 
efficients  corresponding  to  standard  ana¬ 
lytic  functions,  linguistic  modifiers  can 
be  applied  by  simple  modification  of  these 
coefficients.  As  a  result,  the  language 
interpreter  is  very  fast. 

When  radar  signature  datasets  are  fused  in 
the  chaD^board  memory  it  is  necessary  to 
fuse  two  fuzzy  sets  together.  This  fusion 
needs  to  have  the  property  that  as  repeated 
sightings  of  a  similar  feature  value  are 
made,  this  value  becomes  more  and  more  pro¬ 
nounced  in  the  fused  fuzzy  set.  It  is  also 
desirable  to  maintain  the  fused  fuzzy  set 
as  a  piecewise  analytic  function.  This  re¬ 
quirement  is  imposed  to  ensure  the  result¬ 
ing  fuzzy  set  can  be  processed  rapidly 
using  closed  form  arithmetic  when  the  cal¬ 
culation  of  equations  (2)  and  (4)  are  per¬ 
formed  by  the  CHAT  system. 

_ fuaion  of  fuztv  Oata 

To  satisfy  these  two  constraints  we  use  an 
algorithm  which  decays  the  existing  fuzzy 
set  in  chalkboard  memory  by  a  time  constant 
every  update  period.  As  a  new  measurement 


is  fused  with  the  existing  dataset  we  scale 
the  height  of  the  new  measurement  (between 
0  and  1)  to  a  level  incrementally  above  the 
height  of  the  existing  fuzzy  set.  To  mini¬ 
mize  distort’ on  effects,  we  select  the  min¬ 
imum  requited  scale  factor  to  push  the  new 
oataset  up  in  order  to  achieve  visible 
growth  of  the  function  in  the  fused  result . 
Once  the  desired  scale  factor  has  been  cal¬ 
culated,  the  new  dataset  is  fused  by  use  of 
logical  'or'  operator  applied  to  the  two 
datasets.  Figure  11  shows  an  example  of 
the  fusion  algorithm  applied  to  a  set  of  10 
consecutive  fuzzy  feature  measurements. 


10  Beosureaents  received  at 
consecutive  updote  Intervals 
converted  Into  a  fuzzg  set. 


11.  irsBBy  data  fualoa 
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6.Q  Database  Comoreaslon  Techniques 

The  CMAT  database  uses  several  data  com¬ 
pression  schemes  In  order  to  minimize  data 
storage  requirements  by  the  system.  Two  of 
these  compression  algorithms  are  discussed 
below. 

lU _ Chebvshev  fiingtian  Tits 

One  recent  technical  advancement  enabling 
the  compression  of  large  tables  of  refer¬ 
ence  data  for  use  In  an  automated  system  is 
Chebyshev  functional  expansion  of  multidi¬ 
mensional  tables.  This  methodology  simul¬ 
taneously  achieves  three  goals:  large 
tables  or  figures  of  data  are  compressed 
into  a  limited  number  of  expansion  coeffi¬ 
cients,  the  fit  process  Is  a  well  condi¬ 
tioned,  efficient  numerical  procedure  per¬ 
mitting  an  interactive  graphical  interface, 
and  the  average  value  of  the  function,  nec¬ 
essary  to  assessing  the  mean  value  of  the 
data  over  uncertainty  regions,  is  nearly  as 
readily  evaluated  as  the  function  itself. 

This  technique  is  used  in  CMAT  to  encode 
countermeasure  and  maneuver  effectiveness 
data,  threat  launch  envelopes,  and  the  air¬ 
craft  signature  for  use  in  the  situation 
awareness  and  response  strategy  system. 

The  Chebyshev  polynomial  fit  is  closer  in 
method  to  discrete  Fourier  expansions  than 
to  Least  Squared  (LS)  error  polynomial 
fits,  although  the  fit  is  in  terms  of  poly¬ 
nomials.  Instead  of  minimizing  the  fit 
error  at  each  of  the  input  data  points, 
this  method  uses  a  local  polynomial  fit  to 
evaluate  the  interpolated  function  at  pre¬ 
selected  points,  and  then  passes  a  polyno¬ 
mial  curve  through  those  points. 

The  advantages  of  this  approach  are: 

a)  Reduced  operation  count: 
NM(log2(N)+log2(M))  versus  (NM)^ 
in  two  dimensions 

b)  Fit  is  well-behaved  numerically  ver¬ 
sus  ill-conditioned  matrix  inversion. 

c)  Approximate  mln-max  rather  than  LS 
fit  criterion. 

The  purposeful  selection  of  a  fit  criterion 
provides  for  an  efficient  evaluation  of 
Chebyshev  polynomial  expansion  coeffi¬ 
cients.  The  Chebyshev  polynomial  expansion 
coefficients,  C|^,  are  defined  by: 


N 

f(x)  -  ^  C(^Tk-l(x)  -  ic( 

k*) 

The  choice  of  expansion  and  the  discrete 
orthogonality  of  the  Chebyshev  polynomials 
provide*  a  simple  inversion  formula  for  the 
expansion  coefficients: 

N 

cj  -  f(xk)cos(fT(j-n)(k  -  i)/H) 

k-t 

with 

=  coscn  (k-i)/N) 

Thus,  the  evaluation  of  the  coefficients 
requires  an  orthogonal,  cosine  transform  of 
function  values  at  selected  points.  This 
evaluation  is  performed  efficiently  using 
Fast  Fourier  Transform  (FFT)  methods. 
Defining  the  N  point  FFT  of  the  function 
data: 

k-1 

and  phasor  arrays: 

U,-ieiTK|-i)/2H  2,-  ie3nK)-i>/2i» 

'  M  ^  H 

The  coefficients  are: 

cj“  Re(Uj  (Fj+Fh*2-j  )- iZ*(Fj-F|J.2-j  )) 

From  the  Chebyshev  polynomial  expansion  of 
a  function,  a  Chebyshev  polynomial  expan¬ 
sion  for  the  integral  of  the  function  is 
readily  derived  in  terms  of  these  same  co¬ 
efficients.  Thus,  averages  of  the  fit 
function  are  evaluated  as  efficiently  as 
the  function  itself. 

In  CMAT,  the  concern  is  to  maximize  the 
survival  chances  of  ownshlp,  the  probabili¬ 
ties  of  survival  in  the  range  0.5-1  are  of 
more  concern  than  small  probabilities. 

Data  fitting  errors  lead  to  estimated  ef¬ 
fectiveness  values  greater  than  one  or  less 
than  zero.  Both  concerns  are  mitigated  by 
performing  the  curve  fit  to  a  function  of 
the  actual  effectiveness.  The  desired 
function  has  a  conveniently  calculated 
inverse  function,  forces  the  fit  fidelity 
to  be  best  at  higher  effectiveness  values, 
and  limits  the  effectiveness  to  less  than 
unity.  All  these  desirable  features  are 
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achieved  by  the  choice: 

f(x)  =  I  -  (I-P(x))* 

where  a  Is  set  to  between  ^  and  ^  which  is 
the  best  compromise  value  between  fidelity 
and  Integration  convenience.  The  model 
curve  fit  is  made  to  this  function,  rather 
than  to  the  actual  effectiveness  values, 
P<x).  If  any  calculated  value  for  f(x)  is 
less  than  zero,  it  is  truncated  to  zero 
with  no  significant  loss  of  fidelity  since 
effectiveness  values  near  zero  are  of  no 
interest . 

6.2  Effectiveness  Data  Compression 

Efficient  compression  schemes  alone  are  not 
sufficient  to  store  the  countermeasure  and 
maneuver  effectiveness  data  which  is  a 
function  of  four  principal  variables: 
launch  range,  azimuth,  elevation,  and  de¬ 
ployment  time  with  respect  to  the  time  to 
impact  of  the  missile.  In  addition,  there 
is  dependence  on  the  speed  of  the  aircraft, 
and  on  the  speed  of  the  airborne  intercep¬ 
tor  in  air-to-air  engagements,  A  further 
data  compression  scheme  is  used  to  store 
the  effectiveness  data  which  is  a  function 
of  at  least  four  variables. 

This  dilemma  is  solved  by  using  a  fit  which 
is  a  function  of  only  two  principal  vari¬ 
ables,  launch  azimuth  and  elevation.  The 
dependence  on  the  remaining  two  kinematic 
variables,  launch  range  and  missile  time- 
to-go,  is  attained  by  applying  corrections 
justified  by  physical  arguments. 

The  simplified  CMAT  model  for  countermea¬ 
sure  effectiveness'  dependence  on  all  four 
kinematic  variables  first  breaks  down  into 
two  Independent  models,  countermeasure  ef¬ 
fectiveness  and  location  of  ownship  within 
the  threat  launch  envelope.  The  reaction 
is  effective  if  either  the  self-protect 
countermeasure  succeeds,  or  if  ownship 
escapes  the  kinematic  capabilities,  the 
launch  envelope,  of  the  missile.  In  the 
CMAT  model,  effectiveness  adjustments  for 
range  and  tlme-to-go  are  applied  to  the 
curve-fit  effectiveness  data.  No  adjust¬ 
ments  are  made  at  the  optimal  countermea¬ 
sure  deployment  timing,  nor  at  the  center 
of  the  launch  envelope  range.  The  curve- 
fit,  tabulated  effectiveness  values  are  the 
countermeasure  effectiveness  for  midrange 
in  the  threat  launch  envelope,  and  with  the 
countermeasure  deployed  with  the  most  ef¬ 
fective  timing. 


Three  individual  effects  are  accounted  for 
by  the  time-to-go,  t^.,  effectiveness 
adjustment.  First,  if  the  countermeasure 
is  deployed  'too  late' ,  it  cannot  affect 
the  missile  and  therefore  cannot  be 
effective.  The  time  scale  for  'too  late' 
is  determined  by  the  aerodynamic  and 
control  response  time  constant  for  the  mis¬ 
sile,  If  time-to-go  is  less  than  this 

time  constant,  the  effectiveness  of  the 
countermeasure  is  diminished.  The  time-to- 
go  must  also  be  adjusted  for  the  counter¬ 
measure  device  bloom  delay,  1^.  This  bloom 
delay  is  the  time  that  elapses  between  de¬ 
ployment  and  the  onset  of  countermeasure 
effectiveness.  If  <  T^,  the  effective¬ 
ness  vanishes. 

The  second  effect  is  the  duration  of  the 
countermeasure  effectiveness.  If  a  coun¬ 
termeasure  is  effective  for  only  a  limited 
period  of  time,  1^,  the  effectiveness  of 
the  countermeasure  is  reduced  when  it  is 
deployed  too  soon.  This  period  that  the 
countermeasure  is  deceptive  can  be  infi¬ 
nitely  long,  but  typically  is  limited  ei¬ 
ther  by  the  properties  of  the  device  (e.g. 
it  burns  out,  or  decelerates)  or  the  char¬ 
acteristics  of  the  threat  (for  example,  a 
transition  period  is  expended  before  the 
transition  to  home-on-jam  operation,  or  the 
discrimination  of  countermeasure  from  tar¬ 
get)  .  Thus,  the  time  scale  that  determines 
'too  early'  for  the  countermeasure  deploy¬ 
ment  is  fixed  by  this  deception  time,  . 

Another  effect  related  to  the  duration  of 
countermeasure  effectiveness  is  the  period, 
'^Foy,  ownship  dwells  within  the  missile 

seeker  Field-Of-View  (FOV)  after  the  seeker 
has  been  deceived  by  a  false  target .  As 
long  as  the  target  dwells  within  the  seeker 
FOV,  the  seeker  can  recover  ownship,  par¬ 
ticularly  if  the  seeker  can  determine  that 
it  has  been  deceived  by  a  countermeasure  or 
the  countermeasure  loses  its  effectiveness. 
For  example  flares  burn  out,  and  chaff 
decelerates  to  near  the  ambient  clutter 
Doppler.  The  time  period  that  ownship 
dt<ells  within  a  deceived  seeker's  FOV  can 
be  estimated  from  the  engagement  parame¬ 
ters. 

IL _ Wiaic  Meta 

The  CMAT  system  uses  a  mimic  net  to  auto¬ 
matically  capture  knowledge  from  training 
sessions  using  actual  electronic  combat 
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scenarios  and  considered,  expert  selections 
of  reaction  strategy.  The  trained  net  re¬ 
produces  and  generalizes  from  the  training 
In  ways  that  are  tailored  by  secondary 
considerations.  'Maximally  Intuitive', 
'single  cost  emphasis',  and  'maximal 
extrapolation'  are  three  presently  employed 
generalization  techniques.  For  example, 
maximal  extrapolation  requires  maximizing 
the  normalized  separations  of  correct 
options  from  rejected  options. 

The  ability  to  capture  and  reasonably  gen¬ 
eralize  knowledge  Is  a  requirement  to  auto¬ 
mate  complex  tasks.  Even  If  an  automated 
system  Is  meant  only  to  aid  a  human  In  the 
accomplishment  of  complex  tasks,  proficien¬ 
cy  In  the  application  of  accumulated  knowl¬ 
edge  Is  required.  Since  for  complex  tasks, 
human  experts  can  not  always  fully  articu¬ 
late  the  'rules'  that  lead  to  their  deci¬ 
sions,  automated  systems  must  also  be  capa¬ 
ble  of  capturing  a  model  for  the  decision 
process  strictly  from  observations  of  the 
situations  and  selected,  expert  responses. 

A  mimic  net  captures  a  model  of  a  decision 
process  by  examining  experts*  selections. 
The  mimic  net  is  an  algorithmic  system  that 
duplicates  and  generalizes  from  the  ob¬ 
served  situations  and  responses. 

The  mimic  net  Is  employed  to  automatically 
capture  knowledge  from  libraries  of  train¬ 
ing  sessions  that  contain  the  decisions  of 
experts  and  the  options  from  which  each 
expert  decision  was  made.  The  trained  net 
always  reproduces  the  training  data  deci¬ 
sions  when  faced  with  sets  of  options  con¬ 
tained  In  the  training  sessions.  That  is, 
the  mimic  net  has  a  vanishing  mean  squared 
error  (MSE)  for  the  training  data.  The 
training  data  Is  exactly  replicated  by  the 
net.  Rather  than  employing  a  minimum  MSE 
fit  for  the  net  weights  to  the  training 
data,  the  net  is  trained  to  perfectly  re¬ 
produce  the  training  data.  This  Is  the 
'mimic'  quality. 

A  mimic  net  exists  for  every  Internally 
consistent  training  database.  As  long  as 
the  teacher  or  expert  makes  consistent 
choices,  the  mimic  net  will  reproduce  his 
selections  and  Infer  his  rationale.  More 
comprehensive  libraries  of  training  data 
produce  more  accurate  replications  of  the 
expert's  rationale.  Once  the  rationale  Is 
accurately  constructed,  adding  additional 
consistent  training  datasets  to  the  library 
is  redundant. 


Although  mimic  nets  can  both  classify  Input 
features  and  rank  sets  of  Input  features. 

It  Is  used  to  rank  reaction  options  accord¬ 
ing  to  stored,  expert  ratings  of  the  desir¬ 
ability  of  reaction  options  generated  In 
the  CMAT  system.  The  mimic  net  applies  the 
higher  level  tradeoffs  for  ultimate  selec¬ 
tion  of  the  defensive  reaction  strategy. 
Excess  fuel  requirements,  future  value  of 
expendable  resources.  Increased  exposure  to 
other  potential  threats,  are  figured  In 
together  with  reaction  option  survival 
estimates  to  select  electronic  countermea¬ 
sure  reactions. 

The  library  of  data  from  which  to  construct 
the  mimic  net  Is  generated  by  presenting 
Electronic  Warfare  (EW)  experts  with  combat 
scenarios.  The  EM  experts,  pilots.  Intel¬ 
ligence  analysts,  and  tacticians,  select 
their  best  estimated  response  to  each 
threatening  scenario.  The  mimic  net  cap¬ 
tures  these  training  scenarios  Into  a  set 
of  standard  linear  programming  objective 
functions,  and  uses  these  objective  func¬ 
tions  to  generalize  to  new  scenarios.  The 
training  procedure  Includes  generation  of  a 
set  of  features,  quantities  that  specify 
each  scenario.  These  features  include  the 
survival  frequency  estimation  from  CMAT, 
fuel  costs,  time  remaining  In  the  mission, 
mission  phase,  and  measures  of  Increased 
exposure  due  to  each  reaction. 
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1.0  INTRODUCTION 


The  projected  tadar  eleotionuignetic  environments  (erne) 
for  the  I990’s  and  beyond  include:  higher  pulse 
densities  (several  million  pps);  frequencies  to  40  GHz 
and  higher,  stable,  jittered,  staggered  and  pseudo-random 
pulse  repetition  intervals  (PRls)  with  multiple 
frequencies;  spread  spectrum  techniques;  multiple  agile 
radar  beams  and  multi-mode  missile  seekers.  Electronic 
Support  Measures  (ESM)  concerns  the  passive  detection 
and  identification  of  radar  signals.  Thus,  an  ESM 
system  which  can  measure  such  signal  characteristics 
will  most  likely  fkxxl  its  main  processor  with 
information  to  such  an  extent  that  it  may  not  be  able  to 
cope.  In  addition,  missing  pulses  and  receiver/processor 
shadowing  times  may  lead  to  degraded  input  data  to  the 
processor.  A  number  of  likely  solutions  exist  ranging 
from  special  puipose  hardware  to  new  processing 
techniuues.~iFor  the  former,  one  could  argue  the  speed 
jf  digital  hardware  technology  developments  is  such  that 
the  newest,  fastest  SBC  (Single  Board  Computer)  will 
handle  all,  especially  with  RISC/ASIC  assistaiKe;  this 
may  be  true  and  it  is  acknowledged  as  such.  However, 
in  this  paper,  a  radically  different  processing  approach  is 
reviewed,  namely  that  of  neural  networks. 


In  the  past  few  years,  neural  networks  have  shifted  from 
being  primarily  a  research  technology  to  active  use  in 
wide-ranging  defetKe  applications.  \  A  recent  AFCEA 
publication  (ref.  1)  on  DARPA-ft|jwrd  activities  is  the 
.jninl  up  i»<iwrybliaMniii  Ull'^uch  work. 


‘This  paper  will  indicate  the  likely  applicability  of  a 
neural  processing  approach  to  a  range  of  ESM  fuiKtions 
together  with  results  ht>m  some  preliminary  proof-of- 
concept  investigations. 


2.0  USM  .SYSTF.M.S  AND  CONVENTIONAL 
PROCESSING  ARCHITECTURES 

2.1  ESM  FUNCTIONALITY 


subsystems  can  be  realized  in  both  hardware  and 
software  as  follows; 

2.1.1  Feature  Extractor 

This  is  the  RF  front-end  of  the  ESM  system  which 
capmres  the  iiKident  RF  signal  energy  and  makes 
measurements  such  as;  radio  hequeiKy,  time  of  arrival 
(TOA)  of  each  pulse,  pulse  width,  amplitude,  bearing, 
modulation-on-pulse  (MOP).  Such  measurements  are 
then  assembled  into  a  digital  word  (called  a  pulse 
descriptor  word  or  pdw).  Continuous  wave  (CW)  signals 
are  also  measured  and  flagged  within  the  pdw. 

2.1.2  Tracker 


This  raw  sensor  output  will  then  be  pre-processed  by  the 
tracker  subsystem.  The  tracker  is  typically  special- 
purpose  digital  hardware  for  monitoring  the  itKoming 
pdw  data  stream.  It  will  review  incoming  data  by 
comparing  such  measured  parameters  as  RF,  bearing  and 
pulse  width  with  previous  data  already  loaded  into  a 
window  addressable  memory  (WAM).  liKoming  data 
which  matches  a  WAM  entry(ies)  will  be  deemed  as 
being  from  an  already  detected  emitterfs)  and  this  will 
be  monitored,  subsequently,  for  any  parameter  changes 
in  order  to  readjust  the  WAM  values.  Also,  emitter 
update  reports  will  be  sent  to  the  man  machine  interface 
(MMl).  New  incoming  emitter  data  will  not  match  any 
current  WAM  entries  and  thus  will  fall  through  to  the 
next  subsystem. 

2.l»^  Deinler  leaver 


Previously  unseen  emitter  data  will  arrive  at  the 
deinterleaver,  whose  fiiiKtion  is  to  extract  the  individual 
emitter  pulse  trains;  it  does  this  by  recognizing  cenain 
parameters  of  the  pulse  train  such  as  pulse  repetition 
interval  (PRI)  and  then  extracting  all  those  pulses  present 
in  the  input  data  deemed  to  have  come  from  the  same 
emitter.  Additionally,  characteristics  such  as  frequetKy 
agility,  PRI  stagger/jitter  will  be  derived  aitd  an  emitter 
repon  compiled  for  onward  transmission  to  the  Identifier 
subsystem. 


An  ESM  system  usually  comprises  a  number  of  distinct  Initially,  upon  equipment  switch-on,  all  the  data  will 

subsystems,  as  shown  schematically  in  Figure  I;  these  pass  to  the  deinterleaving  subsystem;  however,  the  ESM 
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system  will  eventually  teach  a  steady  state  whete, 
pethaps,  only  10%  of  the  data  will  be  new.  This 
preprocessing  concept  (2.1.2  and  2.1.3)  is  a  particularly 
powerful  technique  in  ESM  systems  since  it  means  that 
the  deinterleaver  is  focused  on  new  data  only  rather  than 
reprocessing  data  it  has  already  handled. 

2.1.4  Identifier 

it  is  the  function  of  the  identifier  to  indicate  the  emitter 
type  using  the  emitter  reports  provided  by  the 
deinterleaver.  Traditionally,  this  is  derived  by 
comparing  the  measured  characteristics  in  the  emitter 
report  with  a  set  of  a  priori  data  contained  in  a  library. 
Also,  the  identifier  may  be  able  to  correlate  an  emitter 
identification  with  a  platform  type  (e.g.,  class  of  ship, 
type  of  aircraft,  submarine).  This  correlation  is  more 
difficult  to  establish  sitKe  one  emitter  type  may  be 
mounted  on  several  different  platforms,  introducing 
ambiguity.  The  identifier  information  will  also  be 
passed  to  the  operator  via  the  MMI. 

2.1.5  Tactical  Situation  Analyst  (TSAI 

From  ref  (6),  this  will  attempt  to  resolve  emitter 
ambiguities  (from  the  library  searching  techniques 
above)  through  various  spatial  and  temporal  correlation 
techniques.  Those  emitters  that  cannot  be  identified  with 
high  confidence  will  be  passed  to  a  hypothesis  generator, 
this,  in  turn,  will  postulate  one  or  more  hypotheses  on 
the  identity  of  the  emitter,  and  then  assign  resources  to 
prove  or  disprove  these  hypotheses.  As  shown  in 
Figure  1,  the  TSA  will  have  direct  links  to  all  the 
subsystems  since  it  may  test  its  hypotheses  at  any  or  all 
stages  of  the  processing  chain.  So,  for  example,  if  the 
TSA  is  attempting  a  platform  identification  for  a 
particular  emitter  then  it  may  produce  a  list  of  possible 
candidates  based  on  such  data  as: 

-  emitter  reports  received  to  date; 

-  geographical  area  of  the  ESM  platform;  and 

-  state  of  conflict/peace,  tension,  hostilities. 


This  list  may  contain  several  candidates  and  the  TSA 
wants  to  home  in  on  the  actual  one.  To  refine  this 
further,  the  TSA  may  then  task  the  deinterleaver  to  see 
if  it  can  detect  certain  specific  emitters  (within  the  new 
data);  detection  of  these  specific  emitters  would  remove 
certain  ambiguities  and  thus  allow  the  TSA  to  pass  on  an 
unambiguous  platform  identification  to  the  MMI. 

Similarly,  the  TSA  will  likely  use  more  of  the  library 
data  than  is  used  by  the  Identifier.  The  TSA  would  most 
likely  use  a  library  structured  in  such  a  way  as  both  to 
show  inter-relationships  amongst  the  characteristics  as 
well  as  to  facilitate  optimum  search  strategies. 

2.1.6  Current  Techniques  for  ESM  Processing 

Basically,  these  can  be  subdivided  into  the  following 
categories,  namely; 

a)  Dedicated  Dieorocessine 

This  is  essentially  a  sotting  process,  which 
selectively  captures  and  (possibly)  stores  data 
based  on  programmable  parameter  windows. 
These  parameter  windows  are  programmed  with 
parameter  ranges  corresponding  to  emitters  which 
have  been  previously  detected  (and  thus  have 
been  reported  to  the  MMI).  This  preprocessing 
technique  is  a  critical  one  in  that  the 
deinterleaving/identification  functions  are  not 
overloaded  with  continuously  sotting  previously 
seen  emitters  and  thus  their  availability  is 
maximized  for  handling  the  ^ew^nknown  data. 
As  mentioned  above,  the  preprocessor  is  typically 
implemented  using  digital  hardware  (WAMS,  e.g.) 
in  order  to  keep  up  with  the  high  input  data  rate. 
Additionally,  there  would  reside  a  specific 
controller  which  autonomously  adjusts  the  filter 
parameter  window  so  as  to  keep  centred  on  the 
data. 


Figure  I. 
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b)  Traditional  signal  processing  algorithms 

For  new  data,  a  range  of  signal  processing 
algorithms  can  be  invoked;  these  would  include; 

clustering  -  so  as  to  conduct  a  preliminary 
grouping  of  the  data,  typically  in 
(RF,  beating,  pulse  width)  space. 

deinierleaving  -  the  extraction  of  repetitive  PRI 
patterns  (jiner,  stagger,  e.g.)  using 
TOA  information  (mainly). 

flagging  -  from  a  determined  PRI,  to  identify 
those  pulses  making  up  the  actual 
pulse  trains. 

scan 

deteimination  -  derive  the  scan  type,  and 
characteristics,  horn  an  amplitude- 
lime  history. 

identification  -  assignment  of  an  emitter  type  to  a 
deinterleaved  emitter  report. 
Currently,  ESM  libraries  are  just 
collections  of  customized  records 
accessed  by  search,  retrieval  and 
update  procedutes.  A  successful 
match  on  search  is  generally 
considered  to  establish  a  detection. 

Typically,  these  algorithms  are  executed  in  a 
serial  fashion  for  any  buffer  of  new  input  data 
(although  multiple  instantiations  could  be 
executed  in  parallel). 

c)  A I  techniques 

The  use  of  AI/KBS/Expert  System  (ES) 
techniques  is  now  being  actively  developed  in  the 


EW  community  and  thus  brief  mention  is  included  here. 

Areas  of  specific  interest  to  ESM  include: 

-  library  structure  and  searching  techniques.  From 
ref.  (2)  Canadian  wotk  is  ongoing  into  both  an 
object  orioited  emitter  library  as  well  as  an 
emitter  classification  system  based  on  symbolic 
reasoning. 

-  hypothesis  testing.  As  indicated  in  ref.  (2),  such 
testing  can  be  invoked  for  identification 'purposes 
in  order  to  deteimine  which  emitter  type  (out  of 
a  range  of  candidates)  best  describes  the  true 
source  of  the  observed  signaL  Additionally,  there 
may  be  scope  for  such  techniques  within  the 
deinterleaving  function  itself. 

-  auto  operator  assistant  and  situation  assessment. 
Aids  the  operator  in  deteimining  the  disposition, 
composition,  and  intent  of  the  platfoims  thought 
to  be  operating  within  the  ship’s  area  of  interest. 
Since  both  emitter  and  platform  identifications  are 
often  ambiguous,  there  will  usually  be  a  number 
of  tactical  situations  which  could  explain  a  given 
set  of  observations.  An  inferencing  system  based 
on  beliefs  could  determine  the  most  likely 
interpretations  of  the  observed  signal  data. 

3.0  NEURAL  NETWORKS  APPROACH 


3.1  GENERAL 

A  neural  network  is  a  massively  parallel,  information 
processing  architecture  composed  of  many  simple 
processing  elements  interconnected  to  achieve  certain 
collective  computational  capabilities.  Neural  netwotks 
are  constructed  of  many  processing  elements  (or 
neurons),  as  shown  below. 
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Each  pfocessing  element  may  have  many  ii^jut  signals 
but  is  limited  to  only  one  output  signal  (which  may  go 
seveial  ways).  Processing  elements  can  be  feed-  forward 
only,  or  have  feedback  loops  as  well.  Also,  processing 
elements  can  be  fully  connected  to  all  the  other 
processing  elements  or  linked  only  to  a  few  (sparsely 
connected).  Any  given  neural  netwoik  design  will 
dictate  the  nature  and  number  of  these  feedback  loops 
and  connectors.  Clearly,  connectivity  relates  to  the 
network’s  parallelism  whilst  the  design  of  its  feedback 
loops  has  implications  for  the  networks 
adaptivityArainability. 

If  the  sum  of  the  inputs  to  a  given  processing  element 
exceeds  a  predetermined  threshold,  the  processing 
element  "fires”  and  sends  a  signal  to  the  other  connected 
processing  elements.  As  shown  above,  each  input  has  a 
weighted  value  that  determines  the  strength  of  the 
interconnection  to  the  fire  or  non-fire  decision  of  the 
following  processing  element.  This  value  can  be  auto-, 
or  self-,  adapting  through  feedback  loops  and  this  is  the 
unique  and  outstanding  feature  of  a  neural  network. 

3.2  NEURAL  PROCESSINC  -  IMPORTANT 
FEATURES 

Conventional  approaches  to  target  detection  and 
classification  typically  include  explicitly  formulated 
algorithms,  software,  and  hardware;  included  will  be  an 
analysis  and  development  of  specific  feature  extraction 
and  pattern  recognition  algorithms  which  then  dictate 
design  and  implementation.  The  challenge,  for  any  such 
signal  processor,  is  to  accept  "raw"  sensor  signals  as 
input  and  provide  target  classifications  as  output.  The 
feature  that  most  distinguishes  neural  network  processing 
from  conventional  signal  processing  is  the  ability  to 
uitemally  develop,  or  "leam",  the  algorithms  required  for 
target  detection  and  classification;  this  includes  the 
extraction  of  specific  target  signatures  buried  in  noise. 
Because  of  their  adaptive  nature,  neural  networks  can 
adapt  to  changes  in  the  data  and  leam  the  characteristics 
of  input  signals.  Funhermore,  because  of  their  non¬ 
linear  nature,  neural  networks  v.an  perform  functional 
approximation  and  signal  filtering  operations  which  are 
beyond  optimal  linear  techniques.  The  architecture  and 
operation  of  a  netwoik  is  fundamentally  different  from 
conventional  signal  processors;  such  a  processor  would 
require  minimal  front-end  analysis  and  design,  no 
explicit  algorithms,  and  no  software.  Additionally,  since 
they  are  naturally  massively  parallel,  this  suggests  a 
decision  making  ability  which  is  both  high  speed  and 
fault  tolerant. 

As  indicated  in  Section  1.0,  erne’s  facing  future  ESM 
systems  will  likely  be  complex  and  of  high  density. 
Additionally,  the  massive  databases  that  exist  on 
recorded  signals  (eliiM/comint  data)  probably  means  that 
adequate  training  sets  exist  with  which  to  train  such 
neural  processors. 

A  list  of  the  attributes  of  a  neural  network  approach  as 
it  applies  to  our  problem  is  as  follows: 


3.2.1  There  exist  direct  theoretical  relationships 
between  other  successful  learning  algorithms 
(such  as  Kabnan  filters)  and  neural  netwoik 
learning  algorithms.  This  adds  an  essential 
mathematical  credibility  to  the  whole  concept  of 
neural  networks.  It  also  means  that  much  of 
existing  mathematical  theory  for  filtering  and 
panem  recognition  can  be  translated  to  the 
neural  netwoik  domaiiL  The  back-propagation 
learning  algorithm  for  layered,  feed  forward 
network  represents  a  major  advance  in 
effective  neural  network  learning.  Back 
propagation  is  a  learning  algorithm  which  is 
designed  to  solve  the  problem  of  choosing 
weight  values  for  hidden  units  in  a  layered  feed 
forward  netwoik  which  has  been  shown  to  be 
directly  related  to  the  extended  Kalman  filter. 

3.2.2  It  is  necessary  to  find  a  compact  set  of  features 
which  can  represent  an  emitter,  it  is  also 
important  that  the  feature  set  be  sufficiently 
complete  so  that  emitters  can  be  ai^ropriately 
discriminated  (e.g.,  friendly/hostile,  as  well  as 
between  defined  types).  Neural  network 
technology  can  contribute  to  the  feature 
selection  task  in  a  number  of  ways,  namely: 

3.2.2. 1  By  providing  hardware  for  massively  parallel 
implementations  of  traditional  feature  detection 
algorithms.  Whereas  special  purpose  parallel 
hardware  could  always,  in  principle,  he 
constracted  for  a  specific  problem,  the  hardware 
would,  in  general,  be  limited  to  only  that 
particular  problem.  One  of  the  things  that  a 
neurocomputer  offers  is  the  possibility  of  not 
only  solving  one  problem  in  parallel,  but  a 
broader  variety  of  problems,  through  (e.g.) 
simple  downloading  of  netwoik  piarameters. 

3.2.2.2  Neural  networks  can  implement  optimum 
feature  receivers  for  the  extraction  of  weak 
features  from  high  clutter  environments. 

3.2.2.3  Certain  netwoiks  have  the  capability  of  self¬ 
organization,  so  that  training  data  can  be 
clustered  without  provision  of  "correct"  outputs. 
Thus,  neural  netwoik  technology  can  contnbuie 
to  the  feature  selection  task  through  the 
automatic  discovery  of  clustered  features  by 
using  neural  network  learning  algorithms. 
Techniques  similar  to  principal  components 
analysts  (e.g.)  can  be  used,  which  have  the 
ability  to  adapt,  so  as  to  represent  the 
characteristics  of  the  input  signal. 

3.2.2.4  Given  their  well-documented  ability  to  perform 
in  the  presence  of  noise  and  incomplete  data, 
neural  netwoiks  can  be  made  much  more  robust 
than  conventional  algorithms  when  dealing  with 
missing  pulses.  Thus,  in  wartime,  the 
performance  of  neural  netwoiks  should  degrade 
gracefully  rather  than  catastrophically. 

3.2.2.5  Neural  netwoiks  have  a  capability  to  integrate 
automatically  a  diverse  set  of  features.  In  the 
ESM  case,  parameters  such  as  (RF,  pulse  width. 
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bearing,  MOP,  polarization,  scan  type)  are 
impoitant  for  target  identification.  However, 
there  is  no  obvious  metric  available  which 
combines  such  features  into  an  effective 
classifier.  The  back-propagation  algorithm, 
combined  with  an  appropriate  training  set,  could 
be  effective  here. 

3.2J  Although  more  speculative,  neural  networks 
may  also  provide  tools  for  developing  expert 
systems;  they  can  implement  propositions  and 
constraints  with  the  capability  to  backtrack  for 
explanations.  InfereiKing  techniques  can  be 
developed  to  allow  the  expert  system  to  teach 
conclusions  when  only  a  fraction  of  the  input 
values  are  known.  (However,  it  should  be 
noted  that  a  lot  of  development  is  still  requited 
to  produce  a  high  performance  neural  network- 
based  ES.] 


4.0  E.SM  PROCESSING  REQUIREMENTS 

Table  1  shows,  for  each  ESM  subsystem  (described 
earlier)  the  likely  input  data  rates  and  a  translation  of 
functionality  into  a  definition  of  the  likely  computer 
instructions  per  second  required  to  give  this 
functionality.  It  can  be  seen,  even  with  today’s 
environments  and  requirements,  that  the  ESM  processing 
requirements  can  carry  up  to  many  millions  of 
instmctions  per  second.  Table  1  also  makes  the  point 
that  not  all  ESM  functions  are  operating  at  the  same 
levels  of  speed:  for  example,  the  tracker  (from  Fig.  1) 
has  to  keep  up  with  the  input  pdw  rate.  However,  the 
identifier  need  only  work  at  the  level  of  a  few 
repons/second.  This  is  a  very  impoitant  point  to 
remember  when  discussing  ESM  processing  perfoiinance 
requirements. 

Trends  in  future  electromagnetic  environments  can  be 
categorized  as  follows,  namely: 

a)  Increasing  density,  and  complexity,  of 
electromagnetic  environments.  Signal  complexity 
is  evident  in  intrapulse  signal  modulations  (such 
as  chirp  and  phase  coding)  as  well  as  increasing 
agility  in  both  individual  signal  features  (such  as 
RF,  pulse  width,  and  PRF)  and  in  combination. 
Signal  densities  are  rising  due  to  the  increasing 
use  of  high  duty  cycle  waveforms  against  an 
iiKieasing  background  environment  from  more 
conventional  sources.  Thus  new  algorithms  are 
continually  required  to  recognize  the  ikw  emitted 
signals. 

b)  Certain  "traditional"  processing  characteristics 
such  as  scan  information  will  soon  be  uruivailable 
due  to  emitter  electionic  scanning  developments. 
Such  future  thrusts  push  the  ESM  system 
designers  towards  architectutes  which  cqmiie 
every  pulse  (or  pulse  group)  and  then  extract  the 
nsaximum  amouiN  of  mfotmation  from  it. 
Intiapulse  mothilation  measuienients  will  call  for 
high  sampling  rates,  thus  Aulher  accelerating  the 
date  infNit  proMem. 


c)  Emitter  war  modes  create  a  well  known  problem 
for  conventional  library  searching  strategies. 

d)  Own/friendly  emissions  could  also  be  exotic  or 
high  duty  cycle,  thus  creating  new  problems  for 
the  ESM  system  designer. 

e)  An  increasing  awareness  for  strict  EMCON 
control  until  the  last  minute,  puts  increasing 
emphasis  on  an  ESM  function  which  works  in 
real  time  even  on  the  most  complex  emissions. 

f)  Overlapping  signal  parameters  (e.g.,  RF,  PW 
bearing)  between  probably  all  combinations  of 
hostile  and  friendly  emissions  will  result  in 
problems  for  a  dedicated  preprocessor.  For 
example,  tracking  of  individual  emitters  will  be 
more  difficult  and  thus  its  integrity  will  degrade; 
this,  in  turn,  will  result  in  fragmented  old  and  new 
data  being  passed  to  the  deinterleaver  which 
would  result  in  false  repoits.  The  efficiency  of 
PRI  predictive  gating  is  f)eih:q>s  questionable 
given  the  numbers,  and  ranges,  of  emitters 
appearing  with  various  amounts  of  PRI  agility. 
Thus,  dedicated  preprocessor  hardware  may  be 
limited  in  its  future  performance. 

The  authors  have  not  attempted  to  show  how  Table  1 
might  change  to  accommodate  the  above  postulations. 
Suffice  it  to  say,  we  see  significant  problems  facing  us 
as  we  design  future  ESM  systems.  We  believe  that  both 
estabhshed  and  new  techniquesAechnologies  need  to  be 
investigated  for  their  applicability  to  this  problem.  As 
we  will  show,  a  neural  processing  approach  is  gathering 
momentum  and  it  may  provide  some  clues  to  resolve  the 
above  scenario. 


5.0  ESM  SYSTEM  OPPORTUNITIES 

It  must  be  stated  that  it  is  not  the  intent  of  this  piaper  to 
prove  that  neural  processing  is  the  only  technique  for 
future  ESM  processing  needs.  Rather,  it  is  to  say  that 
neural  processing  would  appear  to  have  some  significant 
attributes  which  are  directly  applicable  to  the  problems 
foreseen  in  the  ESM  domain.  Neurocomputing  is  a 
fundamentally  new  and  different  information  processing 
scheme;  neural  networks  are  able  to  derive  an 
infonnation-processing  function,  or  algorithm,  from 
examples  of  that  function's  operation. 

From  Figure  1,  the  following  areas  of  specific 
applicability  of  neural  netwoiks  are  proposed  and 
discussed. 

5.1  DEINTERLEAVING 

5.1.1  A  range  of  possibilities  exist,  namely: 

a)  The  ability  to  cluster  in  a  hyperspace  of  high 
dimensionality  so  as  to  include  all  possible 
measured,  and  derived,  features  of  the 
emitter  signal.  So,  for  example,  all  single 
pulse  data  mcluding,  perhaps,  represoitations 
of  specific  transfonnations  (such  as  Fourier 
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coefficients  on  RF  vambility  within  the 
pulse)  could  be  included.  In  a  trained 
netwofk,  all  of  these  features  which  are 
implicit  in  the  input  data  are  handled 
automatically  by  the  netwoik's  connection 
weights.  Currently,  systems  use  only  a 
relatively  small  set  of  feattiies  are  used  with 
a  high  level  of  overlapping  parameters 
between  emitter  types  thus  leading  to 
ambiguous  and/or  erroneous  results. 

b)  Optimum  selection  of  features  (from  a  much 
wider  range  of  single  pulse  features)  for  PRI 
extraction;  for  example,  pulse  shape  features 
may  be  useful  as  well  as  intentional/ 
unintentional  modulation  information. 
Currently,  PRI  is  extracted  using  a  TOA 
difterence  histograming  techniques;  this 
approach  has  limited  success  when  the  input 
data  stream  is  incomplete  or  has  exotic 
characteristics  (such  as  multi-level  staggers, 
e.g.).  Neural  networks  can  perform  their 
own  feature  extraction  and,  with  sufficient 
data,  it  should  be  possible  for  a  network  to 
discover  a  more  appropriate  set  of  features 
by  analyzing  the  pulse  profiles  directly. 

c)  Improved  PRI  extraction  possibilities, 
especially  for  the  exotic  agility  patterns. 
Thus,  a  neural  network  may  be  able  to 
pattern  match  rather  than  time  window 
matching  to  extract  PRI.  As  in  (b), 
currently  the  flagging  of  the  constituent 
pulses  in  a  pulse  train  is  conducted  using 
time-windowing  techniques.  This  is  quite 
complex  even  for  low  levels  of  stagger. 
Also,  non-jittered  and  jittered  signals  are 
difficult  to  extract  in  the  presence  of  each 
other  due  to  an  overlap  in  their  definitions 
(i.e.,  unjittered  =  x%  spread  whilst  jittered  = 
y%  spread  but  which  encompass  x). 

d)  The  recovery  of  noise-corrupted  or  LPl 
signals.  Currently,  ESM  systems  invoke  the 
deinierleaving  process  once  they  have 
declared  an  intercept;  typically,  this  relates 
to  having  received  a  minimum  number  of 
pulses  that  are  clustered.  Should  the 
measured  input  signal  have  only  a  few 
pulses,  or  be  of  such  poor  quality  that 
successful  clustering  did  not  take  place,  then 
deinterleaving  may  not  be  instigated.  Neural 
netwoiks  offer  the  possibility  of  being  able 
to  make  something  of  such  data  inputs. 
Neural  neiwofks  are  much  more  robust  than 
conventional  algorithms  when  dealing  with 
missing  pulses.  In  fact,  they  can  be  made  to 
yield  a  figure  of  merit  for  the  suggested 
classification  they  produce,  allowing  very 
graceful  degradation  in  the  most  difficult 
cases. 

5.1.2  Lockheed  Canada  Inc.  (Lockheed  Canada)  own 

research  in  this  area  has  been  concentrating  on 

two  major  areas,  namely: 


a)  Deinterleaving  using  conventional  signature 
parameters  such  as  RF,  bearing,  pulse  width 
and  pulse  repetititm  interval  (PRI). 
Specifically,  a  range  of  dense  and  exotic 
erne’s  have  been  simulated  which  include  a 
number  of  "target"  emitters  to  be  found  by 
the  neural  network.  The  performance  of  the 
netwofk  is  then  monitored  as  the 
dimensionality  of  the  input  data  (and  thus 
the  complexity  of  the  network)  is 
progressively  increased. 

b)  Unintentional  modulations  (as  well  as  pulse 
shape,  etc.)  within  a  pulse  are  likely  to  offer 
significant  processing  improvements  for 
future  ESM  systems  as  digital  signal 
processing  technology  approaches  the  speeds 
required.  This  specific  work  relates  to  the 
training  of  a  network  with  real  intrapulse 
data  and  examining  its  ability  to  segregate 
emitters  using  such  features.  This  is 
followed  by  incorporating  such  an  ability 
into  the  network  developed  in  (a)  above  in 
order  to  quantify  any  performance 
improvements  in  the  neural  deinterleaver. 

Using  conventional  pattern  recognition 
approaches,  we  are  also  establishing  a  baseline 
performance  "figure  of  merit”;  this  is  essential  if 
we  are  to  understand  the  relative  performance  of 
neural  networks  in  this  particular  ESM  function. 
For  this  task,  we  are  using  both  the  leave-one- 
out-method  as  well  as  the  Kohonen-Loeve 
transform. 

5.1.3  Preliminary  Lockheed  Canada  results  have 
concerned  the  extraction  of  a  high  level  PRI 
staggered  signal  in  the  presence  of  noise.  The 
processing  required  to  identify  the  number  of 
distinct  intervals  in  a  staggered  pulse  train,  and 
the  length  of  the  sequence  of  these  intervals 
(since  some  intervals  may  appear  more  than  once 
in  each  sequence)  can  be  very  time-consuming. 
If  the  length  of  the  sequence  were  known  in 
advance,  the  extraction  of  the  exact  intervals 
from  a  pulse  train  and  the  subsequent 
characterization  of  the  PRI  of  the  train  would  be 
quite  fast  and  efficient.  Lockheed  Canada  has 
designed  a  custom  neural  network  to  identify  the 
length  of  the  stagger  sequence  directly,  together 
with  the  stagger  level.  It  consists  of  an  input 
layer  sparsely  connected  to  a  hidden  layer, 
followed  by  a  standard  back-prc^  style 
connection  to  the  output  layer.  The  network  was 
simulated  in  software,  by  writing  a  small 
program  (14  predicates)  in  PDC  Prolog,  which 
allows  various  sized  nets  to  be  tested  in  an 
interactive  session.  Using  real  trials  recorded 
data  from  single  emitters,  the  net  was  found  to 
identify  stagger  sequence  length  correctly  100% 
of  the  time,  in  spite  of  repeated  intervals,  and 
regardless  of  input  set  size  and  order.  When 
sets  of  data  with  missing  pulses  are  presented, 
the  net  recognizes  this  fact  but  does  not  extract 
the  stagger  level. 
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Follow-on  investigation  involves  training  a 
standard  back-propagation  net  to  recognize  the 
detailed  deviations  in  the  output  of  the  custom 
net  caused  by  missing  data,  and  thus  extract 
stagger  level  in  some  percentage  of  these  cases. 
Lockheed  Canada  now  considers  the  existing  net, 
even  without  the  planned  enhancements,  to  be  a 
useful  module  for  inclusion  in  an  ESM 
processor.  With  simple  neural  chip  support,  it 
would  allow  the  PRl  calculations  for  all  signals 
to  be  handled  in  the  following  sequence: 

1)  Submit  the  pulse  train  to  the  neural  net, 
obtaining  the  length,  L,  of  the  staggered 
interval  sequence  as  an  output.  With  chipset 
support,  and  the  existing  net  architecture, 
this  is  estimated  to  require  less  than  one 
millisecond.  Go  to  2.  If  the  net  signals  bad 
or  ill-conditioned  data  go  to  3. 

2)  Read  the  pulse  train,  calculating  the  time 
deltas,  for  L-t-1  pulses.  Read  another  L 
pulses  to  contirm.  Go  to  4.  If  the 
confirmation  fails  (possibly  try  another 
confirmation  and  if  it  too  fails  then)  go  to  3. 
This  step  is  estimated  in  the  worst  case  to 
require  tens  of  microseconds. 

3)  Go  to  bad  data  handling  routines. 

4)  Return  the  confirmed  stagger  pattern. 

Timings  quoted  here  are  orders  of  magnitude 
faster  than  current  techniques. 

5.2  IDENTIFICATION 

Traditionally,  emitter  reports  are  compared  with  a  priori 
data  held  in  a  library;  typical  algorithms  operate  on  an 
’if-then-else'  type  approach  to  each  library  entry,  where 
hash  coding  typically  defines  the  specific  library  entries 
involved.  Also,  such  algorithms  tend  to  compare 
specific  parameters  in  a  serial  fashion  using  (usually) 
quite  a  small  range  of  parameter  values.  Ref.  (2)  details 
how  alternative,  more  powerful  approaches  are  being 
examined. 

A  Neural  network  approach  could  be  well  suited  for  the 
identification  fiitKtion  in  an  ESM  system  sitKe  lar<re 
training  sets  of  a  priori  knowledge  exist.  It  is  here  that 
the  robustrtess  of  a  neural  network  approach  could  be 
well  tested  against  postulations  of  likely  emitter  war 
modes. 

Once  specific  emitters  have  been  identified,  the  resultant 
network  weights  could  be  noted  and  then  stored  in  the 
library.  Then,  upon  switch-on  of  this  future  neural-based 
ESM  system,  a  much  wider  range  of  library  data  would 
be  downloaded  into  the  network  for  immediate  operation. 

5.3  SITUATION  ANALYSIS 

This  futKtion  does  not,  in  general,  exist  in  current  ESM 
systems.  However,  much  work  is  ongoing  into  sensor 


(and  weapon)  fusion  systems  for  all  three  Services  and 
thus  it  is  only  a  matter  of  time  before  such  capabilities 
appeal  in  an  ESM  system;  Ref.  (2)  describes  one  such 
Canadian  initiative  in  this  area.  As  indicated  above, 
neural  networks  offer  the  promise  of  providing  tools  for 
developing  expert  systems;  one  of  the  major  limitations 
of  AI/KBS/expert  system  work  is  both  the  limited  real 
human  expertise  which  is  to  be  captured  as  well  as  the 
actual  adequate  representation  of  the  rules  and  human 
knowledge.  Neural  technology  would  appear  to  offer 
some  advantages  here. 

5.4  PARAMETER  MEASUREMENT 

During  training,  neural  networks  automatically  build  up 
complex,  non-linear  transfer  functions  which  weight  and 
process  the  input  parameters  as  necessary  to  provide  the 
desired  output.  Analysis  of  the  final  network  state  is  a 
form  of  knowledge  engineering  which  can  yield  valuable 
insights  on  the  relative  importance  of  the  various  input 
parameters  to  the  derivation  of  the  final  classification. 
Such  irtsights  could  be  used  by  hardware  engineers  to 
optimize  future  designs. 

5.4.1  From  ref.  (5),  bearing  estimation  (determining 
the  positions  of  possibly  many  sources  in  the 
scene  from  the  outputs  of  an  array  of  sensors)  is 
a  problem  which  has  been  solved  conventionally 
by  matrix  methods  based  on  singular  value 
decomposition  of  the  data  matrix  or  an  eigen 
description  of  the  covariance  matrix  of  sensor 
outputs.  An  alternative  approach  (refs.  3  and  4 
for  example)  has  been  employed  in  which  the 
bearing  estimation  problem  is  mapped  on  to  the 
Hopfield  network  with  each  "neuron" 
representing  the  hypothesis  that  the  source  is  at 
a  particular  direction.  A  mathematical  cost 
function  is  specified  and  the  evolution  equations 
of  the  network,  which  guarantee  a  convergence 
to  a  (local)  minimum  of  the  cost  function,  are 
solved. 

5.4.2  Current  research  is  underway  at  Lockheed 
Canada  to  evaluate  the  applicability  of  neural 
processing  to  the  discrimination  of  signal  source 
elevations  in  the  presetKe  of  multipath  effects. 
Specifically,  a  network  has  been  trained  using 
signal  propagation  data  containing  both  specular 
and  diffuse  scattering  mechanisms.  Feeding  the 
network  extensive  training  data  for  specific 
sensorAarget  parameters,  trains  the  netw^  '  The 
goal  of  this  work  is  to  determine  the 
perfotmaiKe  of  a  network  in  extracting,  and  then 
tracking,  the  presence  of  specific  target 
characteristics  in  the  presence  of  the  (noisy) 
propagation  environmoit.  Various  network 
architectures  are  under  study  to  ascertain  their 
relative  merits  for  this  application. 

As  agility  in  hequetKy,  PRI  and  other  pulse  train 
parameters  becomes  a  mote  common  feature  of 
emitters,  the  impottatKe  of  precise  and  accurate 
azimuth  and  elevation  measurements  becomes 
greater.  With  this  in  mind,  Lockheed  Caruida 
has  undertaken  an  investigation  of  the  application 
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of  neural  processing  to  high  accuracy  direction 
finding  (HADF).  Before  attempting  to  design 
and  simulate  neural  processors  for  this  purpose, 
it  was  decided  that  the  preliminary  focus  would 
be  on  elevation  measurements  for  a  seaborne 
scenario.  Such  measurements  are  complicated 
by  multipath  interference,  dependent  on  profile 
parameters  such  as  range,  sea  state  as  well  as 
emitter  characteristics  such  as  RP  (see  Fig.  2). 

A  simulation  program  in  Fortran  was  written  to 
generate  data  points  for  emitters  approaching  an 
interferometric  receiver.  Files  of  such  points 
were  generated  for  emitters  at  altitudes  of  from 
10  to  1(X)  meters  by  10  meter  irKrements  using 
an  available  signal  propagation  model  based  on 
extensive  teal  data.  This  range  was  deemed  to 
be  of  interest,  since  obtaining  accurate  elevation 
measurements  within  it  presents  great  difficulty 
for  existing  technologies.  The  network 
simulations  were  created  using  Neural  Works 
Professional  11.  Several  net  architectures  have 
been  tried,  and  the  best  results  to  date  were 
obtained  with  a  Probabilistic  Neural  Net  (PNN). 
Success  rates  as  high  as  96%  on  training  data 
and  80%  on  test  data  have  been  achieved. 
However,  these  results  are  regarded  as 
preliminary,  since  the  complete  set  of 
experiments  originally  envisioned  has  not  yet 
been  completed. 

A  key  problem  is  proper  representation  of  the 
data.  Because  the  patterns  of  frequency  and 
amplitude  as  measured  at  the  receiving  array 
vary  repetitively  with  time  (subject  to  some 
second-order  functions  affecting  speed  of 
variation,  average  power,  etc.),  the  network  must 
be  sensitive  to  trends  over  these  variations,  or  to 
syntactical  representations  of  events  such  as 
multi-path  nulls.  The  planned  follow-on 
investigation  involves  changing  the  data  pre¬ 
processing  and  network  architecture  to  improve 
performance.  Pre-processing  is  aimed  mainly  at 
eliminating  more  of  the  ambiguities  in  the  input 
data  —  or,  equivalently,  enhancing  the  uniqueness 
of  subsets  of  the  data. 


The  choice  of  the  appropriate  network 
architecture  is  to  some  extent  driven  by  the 
nature  of  the  pre-processed  input.  However, 
some  general  observaticms  apply.  The 
probabilistic  net  is  not  favoured  for  hardware 
implementation,  since  its  size  grows  with  the 
size  of  the  training  set;  in  our  case  the  training 
set  is  potentially  huge.  Back  propagation  nets, 
however,  can  slow  the  research  because  of  the 
typically  long  training  time.  The  remainder  of 
the  experiment  plan  calls  for  investigation  of 
various  avalanche  networks  and  self-organizing 
feature  nets.  Some  consideration  is  also  being 
given  to  integration  of  knowledge-based  and 
neural  techniques.  Lockheed  Caiutda  is  well 
placed  to  investigate  this,  since  several  of  the  in- 
house  neural  simulations  have  been  written  in 
Prolog.  This  renders  the  integration  of  the  neural 
net  with  Prolog-based  expert  systems  extremely 
easy. 

6.0  CONCLUSIONS 

Whilst  a  neural  network  is  a  computational  structure 
modelled  on  biological  processes,  we  believe  that  neural 
networks  technology  has  defence  applications, 
specifically  as  an  important  new  technology  for  ESM 
systems.  Their  inherent  parallel  processing  architecture 
offers  the  promise  of  extremely  fast  operation  using  wide 
bandwidth  input  data  streams.  Classification  and 
Associative  memory  possibilities  would  look  to  be  most 
promising  with  ES  assistance  as  a  longer  term  goal. 
Their  ability  to  provide  an  adaptive,  nonlinear  capability 
could  be  most  useful  in  ESM  signal  processing 
applications. 

Lockheed  Canada’s  experience  with  neural  processing 
applications  in  ESM  clearly  establishes  their  usefulness 
as  a  supplement  to  conventional  ESM  processing 
techniques.  It  is  clear  that  hardware  is  r^idly  being 
developed  to  make  realistic  practical  (rather  than 
theoretical)  assessments  possible. 


Figure  2. 
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GLOSSARY 


AFCEA 

Armed  Forces  Communications  and 
Electronics  Circuit 

Al 

Artificial  Intelligence 

ASIC 

Application  Specific  Integrated  Circuit 

CW 

Continuous  Wave 

DARPA 

Defense  Advanced  Research  Projects 
Agency 

EMCON 

Emission  Control 

EME 

Electromagnetic  Environment 

ES 

Expert  System 

ESM 

Electronic  Support  Measures 

HADF 

High  Accuracy  Direction  Finding 

□CBS 

Intelligent  Knowledge  Based  System 

LPI 

Low  Probability  of  Intercept 

MMI 

Man  Machine  Interface 

MOP 

Modulation  on  Pulse 

PDW 

Pulse  Descriptor  Word 

PRF 

Pulse  Repetition  Interval 

PRI 

Pulse  Repetition  Frequency 

RF 

Radio  Frequency 

RISC 

Recfarced  Instruction  Set  Conqiuter 

SBC 

Single  Board  Computer 

TOA 

Time  of  Arrival 

TSA 

Tactical  Situation  Analyst 

WAM 

Window  Addressable  Memory 

Discussion 

1.  Prof.  F.Vagnarelli,  Italy 

About  the  high  accuracy  direction  finding,  which  kind  of 
equipment  has  been  utilized? 

Author; 

We  have  modeled  a  two-element  vertical  phase 
interferometer,  against  sea-skimming  targets.  Amplitude 
and  phase  information  at  each  antenna  is  derived  and  stored 
for  submission  to  the  neural  network. 

2.  T.Schang,  France 

Concerning  the  stagger  extraction  application,  what 
happens  when  mixed  signals  are  used  as  an  input? 

Author: 

The  net  under  discussion  has  a  very  specialized  architecture. 
Mixed  signals  and  missing  data  cause  the  performance  to 
degrade  and  can  cause  absence  of  a  clear  “winner"  in  the 
response  vector.  This  can  be  used  as  a  signal  that  the  data  are 
not  well  clustered,  triggering  the  use  of  other  algorithms  in 
the  system.  Because  the  network  operates  so  quickly,  we 
intend  to  apply  it  to  all  data  coming  from  our  channelizing 
hardware,  using  the  other  algorithms  only  when  it  fails.  We 
are  also  considering  training  a  standard  back-propagation 
net  to  recognize  the  typical  perturbations  in  the  output 
vector  caused  by  missing  and  interleaved  data. 


C  Copyrij^t  Lockheed  Canada  Inc.,  April  1991 
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NEURAL  NETWORK  SOLUTIONS  TO  MATHEMATICAL  MODELS  OF  PARALLEL  SEARCH 
FOR  OPTIMAL  TRAJECTORY  GENERATION 


Lyle  A.  Reibling 

Smiths  Industries  Aerospace  &  Defense  Systems,  Inc. 
4141  Eastern  Avenue,  S.E. 

Grand  Rapids,  MI  USA  49518-8727 


1.  SUMMARY 


c 


The  Grand  Rapids  Division  of  Smiths  Industries 
Aerospace  A  Defense  Systems,  Inc.,  has 
performed  Independent  Research  and 
Development  in  neufal  network  technology  for 
,^icle  management  system  applications  of 
opthu^l  trajectory  generation  in  embedded 
system^  This  paper  describes  the  problem  and 
solution  method  ih  envisioning  massively 
parallel  architectures  which  incorporate 
mathematical  physics  models  for  trajectory 
generation  applications. ' 


-A  difficult  problem  in  search  applications  is 

d - computing  the  optimal  aircraft  trajectory  in 

re^time  onboard  a  high  performance  aircraft, 
where  the  objective  is  to  increase  the  aircraft 
survivability  and  mission  effectiveness  by 
penetrating  enemy  threats  and  minimizing 
threat  radar  exposure.  Optimal  trajectory 
generation  is  achieved'  by  searching  all  possible 
paths  in  a  multidimensional  search  space  for 
the  path  with  the  smallest  accumulated 
performance  measure,  which  represents  total 
threat  exposure.  This  search  problem  has  many 
state  variables  in  a  large  space  which  places 
severe  demands  on  computational  resources, 
requiring  real-time  solutions  unavailable  from 
current  technology.''^ 


r: 


The  mathematical  model  which  is  the  basis  for 
this  architecture  is  based  on  an  application  of 
electrostatic  field  theorvi^3t  dwribes  the 
problem  of  finding  the  best  patS*'^lwmtgh  a 
region  which  contains  a  variable  cost  tuBCHon^ 
as  a  problem  in  mathematical  physics.  One  suw  ^ 
description  is  that  of  finding  the  distribution 
of  current  flow  through  a  nonuniform 
conducting  media,  such  as  a  plate  of 
inhomogeneous  resistive  material.  Another  is 
finding  the  propagation  of  wavefronu  through  a 
medium  with  a  nonuniform  refractive  index. 


This  research  has  investigated  computer 
architectures  and  algorithms  characterized  by 


massive  parallelism  which  can  solve  trajectory 
generation  problems.  An  artificial  neural 
network  is  defined  which  computes  solutions  to 
Held  theory.  Experimental  investigation  of  this 
technique  has  shown  promising  results.  The 
solutions  generated  by  the  architectures  have 
been  checked  against  known  admissible 
algorithm  results  and  shown  to  be  correct. 


2.  INTRODUCTION 

Advances  in  integrated  circuit  and  optical 
computing  technology  have  made 
implementation  of  massively  parallel  computer 
architectures  feasible.  These  architectures  are 
more  complex  than  multiprocessor  networks, 
often  mimicking  the  structure  of  the  brain  for 
their  inspiration.  Computation  is  not  specified, 
or  programmed,  in  the  usual  manner  of  a  stored 
program  computer.  Rather,  the  collection  of 
interconnection  strengths  between  parallel 
processing  elements  determines  the 
computation  of  the  processing  system. 

The  Von  Neumann  architecture  is  a  serial 
processing  architecture.  These  architectures 
require  algorithms  which  are  defined  as  serial 
instruction  streams.  Even  multiprocessors, 
while  processing  in  parallel  as  a  group,  are 
processing  serially  as  individual  processors. 
Problems  growing  in  size  and  computational 
complexity  make  for  more  severe  computing 
demands  upon  serial  processing  architectures. 
To  meet  the  requirements  of  these  larger,  more 
complex  problems,  the  processing  architecture 
and  algorithms  need  to  be  more  closely  matched 
with  the  nature  of  the  application  problem. 

A  general  purpose  sequential  processor,  or  even 
a  group  of  multiprocessors,  may  not  be  effective 
in  solving  traditional  algorithms  for  these 
demanding  problems.  Many  situations  that 
require  real-time  solutions  are  satisfied  with 
the  rapid  computation  of  near-optimal 
solutions.  This  may  even  be  more  desirable  than 
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waiting  for  a  slower  computation  of  the  optimal 
solution.  Examples  include  optimal  control 
problems  such  as  aircraft  flight  control  or 
trajectory  generation  in  which  a  rapidly 
changing  environment  requires  a  fast  solution 
from  the  processing  architecture. 

The  motivation  of  this  research  is  the 
investigation  of  computer  architectures  and 
algorithms  characterized  by  massive 
parallelism  which  have  computational 
properties  that  yield  the  solution  of 
combinatorial  search  problems  with  application 
to  path  planning.  The  problem  is  discovering  a 
model  which  maps  onto  massively  parallel 
architectures. 


3.  NATURAL  PARALLELISM 

Increasingly  complex  problems  create  a  need 
for  the  computing  power  offered  by  massively 
parallel  architectures.  Advancements  in 
computer  architectures  and  hardware 
technology  have  led  to  practical 
implementations  of  massively  parallel 
computing.  Because  of  its  characteristic  of 
collective  computation,  a  new  way[l]  of  thinking 
about  the  role  of  application,  algorithm,  and 
architecture  in  the  design  of  massive 
parallelism  is  needed.  The  design  challenge  is 
to  determine  an  appropriate  model  of  the 
interdependence  between  the  application 
problem  to  be  solved,  the  algorithm  which 
solves  the  problem,  and  the  massively  parallel 
architecture  which  solves  the  problem  using 
collective  computations. 

Recent  developments  in  massively  parallel 
architecture  technology  has  increased  their 
capacity  while  shrinking  their  size.  To 
capitalize  on  the  advantages  offered  by  these 
new  architectures,  a  new  approach  to 
envisioning  design  is  needed.  This  new 
approach  is  based  on  the  capabilities  of 
massively  parallel  architecture  technology. 
Processing  units  of  the  architecture  are 
dedicated  to  explicit,  unique  state  assignments 
of  the  problem,  given  a  suitable  sute  variable 
resolution. 

Consider  how  discovery  of  Nature  is  done. 

Nature  is  observed  and  natural  law  is 
hypothesized.  This  natural  law  is  often 
expressed  as  equations  in  mathematical 
physics.  Therefore,  these  equations  describe 
Nature's  behavior.  When  computing  solutions  to 
these  equations,  a  numerical  simulation  of 


Nature's  behavior  is  performed.  Now  consider 
this  viewpoint  reversed.  Nature  is  the  perfect 
analog  computer  for  these  same  equations. 

Nature  is  the  analogy  for  solving  problems 
described  by  the  equations  of  mathematical 
physics. 

Nature  is  also  described  by  states  and 
operations  transforming  these  states.  This 
provides  another  analogy  to  massively  parallel 
computation.  In  traditional  sequential  computer 
systems,  a  single  processor  fetches  data  from 
memory,  modiHes  the  data,  and  puts  the  data 
back  into  memory.  Consider  however,  memory 
where  the  data  elements  themselves  have  a 
computation  capability.  This  computation  is 
accomplished  by  exchanging  and  modifying 
values  between  the  data  elements  of  the  memory. 
If  the  data  elements  of  the  memory  correspond 
to  the  state  assignments  of  a  problem,  then  the 
values  represent  possible  state  variable 
solutions.  This  structure  provides  an  explicit 
mapping  between  processing  nodes  of  a 
massively  parallel  architecture  and  state 
assignments  of  a  mathematical  physics  problem. 
The  mapping  between  state  assignments  of  the 
natural  analogy  and  the  processing  nodes  occur 
by  a  sampling  of  the  state  space  into  a 
computing  grid  with  an  appropriate  resolution. 

The  process  of  applying  the  paradigm  of  natural 
parallelism  is  to  begin  by  looking  for  analogies 
in  Nature  for  the  problem.  When  an  appropriate 
analogy  is  found,  the  natural  parallelism 
concept  is  formed.  This  conceptual  embodiment 
within  the  paradigm  meets  the  needs  of  the 
massively  parallel  design.  The  relationship  to 
the  application  is  understood  and  is 
explainable.  The  algorithm  is  identified 
through  the  natural  law  of  mathematical  physics 
which  applies  to  the  concept.  The  architecture 
is  mapped  through  the  numerical  techniques 
yielding  the  computational  structure. 

3J _ Applying  Natural  Parallelism 

The  trajectory  generation  algorithm  for  the 
architecture  is  described  as  a  problem  in 
mathematical  physics.  This  application  uses  an 
analogy  of  field  theory  for  the  algorithm  of  the 
mathematical  model.  The  artificial  neural 
network  is  used  for  the  architecture.  Two 
examples  are  provided.  The  Hrst  uses  the 
elecuosutic  model  to  compute  obstacle 
avoidance  paths.  This  provides  for  multiple, 
alternative  paths  to  avoid  discrete  or 
continuous  obstacles.  The  second  example  uses 
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the  wave  propagation  model  for  computing  the 
optimal  path. 

These  mathematical  physics  problems  are 
expressed  as  partial  differential  equations. 
Thus,  the  partial  differential  equation  is  a 
natural  parallelism  in  which  the  problem  is 
viewed  as  one  in  computational  physics.  The 
variable  cost  function  is  similar  to  the 
nonuniform  resistivity  of  the  plate  media,  or 
the  nonuniform  refractive  index.  The  solution  to 
the  appropriate  partial  differential  equation  is 
a  scalar  potential  field  for  the  media.  Paths  are 
computed  from  the  vector  field  orthogonal  to  the 
equipotential  contours  of  this  field. 


4..  MATHEMATICAL  MODELS 

4J1 _ The -Electrostatic  Model  for  Avoidance 

Trajectory  Generation 

The  mathematical  model  for  the  electrostatic 
based  trajectory  generation  approach  is  an 
intuitive  description  of  path  planning.  The 
mathematical  model  is  based  on  a  conjecture 
that  the  problem  of  finding  the  best  path 
through  a  region  which  contains  a  variable  cost 
function  is  analogous  to  the  problem  of  finding 
the  maximum  current  flow  through  a 
nonuniform  conducting  media,  such  as  a  plate  of 
inhomogeneous  resistive  material.  The  variable 
cost  function  is  analogous  to  the  nonuniform 
resistivity  of  the  plate  media.  Boundary 
conditions  for  the  location  of  the  source 
potential  and  sink  potential  are  analogous  to  the 
start  and  goal  nodes,  respectively. 

The  mathematical  model  is  based  on  electric 
field  theory[2].  From  the  definition  for  current 
density  and  its  divergence  in  steady  state 
conditions,  the  n-dimensional  electric  field 
potential  ^  »  ^X],X2,...,Xf«()  of  a  nonuniform 
conductive  media  can  be  derived[3]  as  the 
second  order  partial  differential  equation 

+  p  Vo  V0  =  0  (1) 

where  p  ■  p(X|,X2,...,X]q)  is  the  nonuniform 

resistivity  of  the  media  and  o  =  p*^.  The  cost 
function  is  used  to  model  the  resistivity  of  the 
conducting  media.  Expanding  the  gradient  and 
divergence  operators  in  the  two  dimensions  x 
and  y  results  in  the  following  second  order 
partial  differential  equation 

(2) 


Since  the  electric  field  and  current  density 
results  from  the  gradient  of  a  scalar  Held,  they 
are  conservative  fields,  and  the  field  lines 
emanate  from  source  charges  and  terminate  on 
sink  charges[4].  These  field  lines  represent  the 
solution  to  the  search  problem  as  multiple 
paths.  Several  properties  of  the  paths  are 
noteworthy.  First,  every  heading  from  the  start 
node  has  a  defined  path  due  to  the  continuous 
vector  field  emanating  from  the  source.  Second, 
every  location  which  has  finite  resistivity  has  a 
path  defined  through  it  for  the  same  reason. 
Third,  the  model  supports  zero  and  infinite  cost 
regions. 

The  flux  (field)  lines  f<x  the  elecuostatic  model 
are  used  as  the  path  definitions.  The  flux  lines 
are  computed  once  the  electrostatic  potential 
field  is  derived  for  the  problem  from  the 
solution  to  the  partial  differential  equation. 
There  are  an  infinite  number  of  flux  lines 
which  leave  the  source  point  and  enter  the  sink 
point.  This  is  because  the  source  and  sink 
points  are  singularities  in  the  potential  field 
solution.  At  every  point  in  the  potential  field, 
there  is  a  gradient  vector  (the  electric  field 
vector)  with  the  exception  of  these  two 
singularities.  From  the  source  point,  an  angle  is 
selected  from  which  to  trace  out  the  flux  line. 
This  is  the  initial  heading  at  the  start  node 
(source  point).  Using  a  small  incremental  path 
step,  the  path  progresses  along  this  beading  by 
the  magnitude  of  the  path  increment.  From  this 
point  on,  the  gradient  vector  can  be  computed 
which  will  define  the  direction  of  the  path 
descent  over  the  potential  field  surface,  thus 
obtaining  the  path  as  the  flux  line. 

4.2 _ The  Wave  Fropagation  Madcl  far  Optimal 

Trajectory  Generation 

The  next  development  is  to  change  the  equations 
of  the  model  in  order  to  achieve  the  optimal 
path,  rather  than  the  avoidance  paths  of  the 
electrostatic  model.  Theory  pertinent  to  a  model 
based  on  wave  propagation  phenomena  relates 
various  quantities  which  incorporate  the  cost 
function,  such  as  wavefront  velocity  or 
refractive  index.  Fermat's  Principle  of  Least 
Time  explains  the  propagation  of  light  through 
material  with  varying  refractive  index. 

The  mathematical  model  is  based  on  wave 
propagation  tbeory[5].  The  wave  equation  is 
described  as  the  condition  of  a  physical 
quantity,  i*.  which  satisfies 
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The  cost  function  is  modelled  inversely  as  the 
(3)  wavefront  velocity  for  the  wave  propagation 
model 


where  v  is  the  phase  velocity  of  the  wave  and 
may  in  general  be  a  function  of  the  space 
coordinates  (a  wave  traveling  in  a  non- 
homogeneous  medium).  The  cost  function  is  used 
to  model  the  refractive  index  of  the  optical 
media.  Equipotential  wavefronts  emanate  from  a 
light  source.  These  wavefronts  are  orthogonal  to 
the  light  rays. 

The  light  rays  form  the  paths  of  the  solution. 

The  light  rays  are  computed  from  the  equiphase 
field  of  wavefronts.  This  field  is  a  solution  to 
the  wave  equation.  There  are  an  infinite  number 
of  light  rays  leaving  the  source  point.  The 
source  point  is  a  singularity  in  the  solution. 

The  equiphase  field  is  the  phase  distance  of 
travel  by  the  light  rays.  From  any  point,  a 
gradient  vector  points  to  the  direction  of  travel 
of  the  light  ray  from  the  source  point.  By 
tracing  this  vector  back  to  the  source,  point,  the 
optimal  path  from  the  starting  point  to  a  goal 
node  (the  source  point)  is  found. 

An  expression  for  the  wave  equation  is  desired 
so  the  solution  is  only  a  function  of  the  spatial 
coordinates  of  the  medium(6].  Periodic  solutions 
of  the  wave  equation  can  be  found  from  Equation 
3  where  the  solution  is  assumed  to  be  separable 
into  two  functions.  The  function  '¥  will  depend 
only  on  the  spatial  coordinates,  and  the  other 
function  on  time.  From  this  is  obtained 


c*7  (8) 

As  the  cost  is  higher,  the  wavefront  moves  with 
lower  velocity,  incurring  more  periodic  cycles 
of  the  wave  and  a  higher  accumulated  phase 
distance  along  the  wavefront.  Since  vsds/dt. 
Equation  7,  after  substituting  Equation  8, 
becomes 


min 


;pds 

Is 

dt 


which  reduces  to 


min  I  dt 


(9) 


(10) 


which  is  the  principle  of  least  time  for  the 
wavefront.  Since  the  solution  is  only  based  on 
the  spatial  component,  this  is  like  taking  a 
'snapshot”  of  the  wave  at  some  unique  point  in 
time.  The  accumulated  phase  along  the  light  ray 
corresponds  to  the  accumulated  cost,  and  is  a 
minimum  value  according  to  Fermat’s  Principle 
of  Least  Time. 


5.  NEURAL  NETWORK  IMPLEMENTATION 


v2y  +  =  0 


where 


2xv  (0 


(4) 


(5) 


where  v  is  the  frequency  and  v  is  the  wavefront 
velocity.  Consider  v  as  the  inverse  of  the  cost 
function  .  C.  The  higher  the  cost,  the  slower  the 
propagation  velocity 


5.1  Implementing  the  Electrostatic  Model 

The  partial  differential  equation  for  the 
electrostatic  model  was  derived  for  the 
nonhomogeneous  media,  used  to  represent  the 
cost  function  in  generating  paths  which  avoid 
regions  of  high  cost.  This  section  describes  the 
architecture  design  of  a  neural  network  that 
computes  the  numerical  solution  to  the 
equation.  The  architecture  implements  a  finite 
difference  approximation  to  the  partial 
differential  equation. 


It  is  desired  that  the  partial  differential 
(6)  equation 


The  objective  of  the  optimal  path  problem  is  to 
minimize  the  accumulated  cost  along  the  path 

min  I C  ds  (7) 


d^u  3^0  d^u 
L(u) »  A  — r  +  B  +  C  — r 

^  3*2  3xdy  3y2 

^  au  „  du  „ 

+  D~  +  E~  +  Fu*0 
dx  dy 


(H) 


be  approximated  on  a  unit  grid  by 
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n 

Li(u)  -  OQUp  -  J^OiUQ.  (12) 

i^l 

with  the  n  neighbors  of  P  being  Qi . where 

Qj  =  (x+5j,y+Hi).  Using  a  Taylor  series 
q>proximation  for  the  expansion  of  u  about  P 
results  in  the  system  of  equations 

n 

n 

isl 

i«i^i-D 

isl 

n 

=  2C 
isl 
n 

isl 

n 

Xoi^i^  »  2A  (13) 

isl 

The  solution  of  the  coefficients  of  the  above 
system  of  equations  allows  approximating  the 
value  of  a  grid  point  by  solving  for  up 

1  “ 
isl 

The  nonhomogeneous  Laplacian  equation  of  the 
electrostatic  model  using  the  quantities  C,  s 
and  Cy  s  Oy  is 

and  the  coefficients  of  Equation  11  are  A«l, 
BsO.  Ol,  EsCy.  and  M).  To  derive  a  five- 

point  finite  difference  formula  the  coefficients 
diown  in  Table  1  are  substituted  into  the 
system  defined  by  Equation  13  and  yields  the 
following  system  of  equations 


02  -  04  s  Cy 
“1  -“3*Cx 
02  +  04  =  2 

Ol  -I-  03  s  2  (16) 


Table  1:  Five-Point  Coordinates 


Substituting  Equation  17  into  Equation  14  and 
solving  for  up  gives  the  finite  difference 

formula 


T)”Q3*(i-'t)«Q4  <>»> 


The  block  diagram  of  the  neuron  model  that 
implements  the  five  point  approximation  of 
Equation  18  is  shown  in  Figure  1. 


O]  -f  02  -f  03  04  a  Oq 


Figure  1:  Five-Point  Approximation  Neuron 
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An  artificial  neural  network,  as  defined  by  the 
model,  uses  an  electronic  circuit  shown  in 
Figure  2  as  its  basic  neuron  model,  with  the 
interconnecting  resistors  representing  the 
synapses  between  the  neurims.  The  numerical 
approximation  is  computing  the  solution  to  the 
system  of  equations  (18). 


and  Oy 

.  The 

non-linear  neuron  output 

function 

''i.j  *» 

defined 

as 

-Vref 

“i.j  ^  -Vref 

Vij  =  ' 

'Vref  ^  “i.j  ^  *^Tef 

(20) 

[+Vref 

“i,j  >  +Vref 

Figure  2:  Numerical  Approximation  Circuit 

The  neural  network  is  used  to  perform  a 
parallel  computation  of  the  scalar  potential 
field  #  at  every  spatial  point.  For  the  neural 
network  implementation,  the  neuron  input 
function  u|  j  is  defined  as 

The  synaptic  weights  implement  the  non¬ 
uniformity  of  the  cost  functions  (the 
coefficients  of  Equation  19  which  contain  o^ 


The  entire  search  space  is  constructed  by 
replicating  this  portion  of  the  neural  network 
over  the  entire  grid.  The  output  of  the  source 
and  sink  neurons  which  correspond  to  the  start 
and  goal  nodes  are  clamped  to  and  -Vf^f 

respectively.  Since  the  clamping  of  the  source 
and  sink  to  the  maximum  and  minimum 
(respectively)  potential  value  occurs  on  the 
boundary  of  the  problem,  it  is  iqipropriate  to 
use  these  clamped  values  as  the  limits  of  the 
neuron  output  function  (Equation  20).  since  all 
potential  values  inside  the  boundary  of  the 
problem  are  guaranteed  to  lie  between  these 
limits. 

The  avoidance  paths  are  extracted  from  the 
neural  network.  The  network  computes  the 
scalar  potential  field,  as  described  previously. 
This  is  a  surface  with  a  global  maximum  at  the 
start  node  and  a  global  minimum  at  the  goal 
node.  A  direction  is  selected  for  a  path  at  the 
start  node.  Gradient  descent  over  the  potential 
surface  is  used  to  extract  the  avoidance  path  for 
that  direction.  Bivariate  interpolation  of  the 
potential  values  is  used  between  the  grid  points 
to  form  smooth  paths.  An  illustration  of  the 
model  is  shown  in  Figure  3.  The  contour  lines 
represent  the  cost  function  for  the  problem.  The 
field  lines  represent  the  avoidance  paths 
generated  by  the  model. 


Figure  3:  Electrostatic  Uodel  Example 
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5.2  hnnlementing  the  Wave  Propagation  Model 

The  wave  equation  was  derived  for  the 
nonhomogeneous  refractive  index  of  the  media, 
used  to  represent  the  cost  function  in 
generating  the  optimal  path  through  the  region 
modeled  by  the  media.  This  neural  network 
architecture  cmnputes  the  numerical  solution  to 
the  wave  equation.  The  architecture  implements 
a  parallel  cost  propagation  for  the  accumulated 
phase  distance  of  the  wave  equation. 


k-2 

V  =  5;Cj  (26) 

j=0 

This  means  that 

=  cos(C^.j  +  4*)  (27) 

and  also  that 

iqt.2  =  cosV  (28) 


The  fmward  propagation  of  a  wavefront  in  a 
single  dimension,  x,  is  deflned  with  the  wave 
equation 


d2«l»  - 

— r+K24»*0  (21) 

dx2 

The  calculation  of  solutions  to  this  equation 
also  consists  of  a  forward  propagation  of 
solution  values  (a  computation  wavefront)  by 
using  a  difl'erence  formula.  The  central 
difference  formula  is 


A  stable  solution  is 

sin(C]c  +  Ck-i) 


“k 


sin  .  j 


Uk-l 


sin 

sin  Cfc.  1 


“k-2 


(29) 


In  two  dimensions  the  wavefront  is  defined  by 
min 

“i,j  ~  cos(Cjj  j  ^k,l)  (30) 


yj+l  =  (2-h2K2)«yi 


(22)  where  k,l  are  the  neighbors  of  ij,  and  also  that 


K  is  related  to  the  grid  size.  N,  and  maximum 
wavelength,  so 


Sk,l  =  +  min  (  X  Cs)  (31) 

path  to  k,l 


(2-h2K2)  «  2 


1  - 


2jt2c2  ^ 


n2c: 


max 


(23) 


Substituting  Equation  23  into  Equation  22  gives 
the  resulting  approximation  for  the  cost 
function  grid 


“i+1 


2x2c- 


2  ^ 


1  - 


n2c; 


max 


2ui  -  ui.i 


(24) 


V 


Since  it  is  assumed  that  the  accumulated  phase 
distance  is  the  accumulated  cost  function,  the 
solution  to  the  wave  equation  can  be 
represented  as 

u^  «  cos(Cg  ♦  C|j.j  ♦  '•'k-2)  (25) 


where  C's  are  the  accumulated  phase  distance 
along  the  path  to  k,l. 

The  neural  network  architecture  for  computing 
solutions  to  the  wave  equation  is  similar  to  the 
wavefront  propagation  formula,  but  actually 
propagates  costs  corresponding  to  the 
accumulated  phase  distance  of  the  wavefront. 
Hassoun[7]  has  described  a  technique  for 
solving  path  optimization  problems  using  a 
neural-like  architecture  with  appropriate 
computational  nodes.  His  approach  is  based  on 
Dijkstra’s  algorithm  with  adaptations  made  for 
parallel  computation.  The  architecture  is  a  fine 
grained  locally  interconnected  network  to  find 
the  optimal  path  between  two  points.  An 
alternative  parallel  architecture  and  algorithm 
is  suggested  by  this  research  which  improves 
Hassoun's  algorithm.  Figure  4  is  the 
implementation  of  the  improved  neural  cell  for 
the  network. 


where  without  toss  of  generality  V  =  'l'k.2  *“<1  >* 
defined  according  to  the  assumptimi  above  as 
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Figure  4;  Neural  Network  Cell  Implementation 


An  illustration  of  the  model  is  shown  in  Figure 
S.  The  contour  lines  represent  the  accumulated 
cost  values  for  the  problem.  The  optimal  path 
generated  by  the  model  is  also  shown. 


6.  CONCLUSIONS 

A  significant  result  of  this  research  was  the  use 
of  a  new  paradigm  to  design  massively  parallel 
architectures.  This  new  paradigm  was  ctdled 
natural  parallelism.  The  natural  law  which  was 
employed  to  investigate  the  paradigm  was  a 
class  of  partial  differential  equations  in 
mathematical  physics.  These  partial 


differential  equations  describe  physical 
phenomena  in  electromagnetic  Held  theory. 
Using  natural  parallelism,  these  physical 
phenomena  were  shown  to  describe  certain 
optimization  problems.  Nature  was  viewed  as  an 
optimization  process,  exhibiting  equivalent 
behavior  for  which  mathematical  expressions 
are  available  (that  is,  the  partial  differential 
equations  of  electromagnetic  field  theory). 

Using  the  paradigm,  an  artificial  neural 
network  was  designed  which  can  solve  a  class  of 
partial  differential  equations.  Natural 
parallelism  provided  two  mathematical  models 
in  electromagnetic  field  theory  as  analogies  for 
the  problem  of  trajectory  generation.  They  were 
the  electrostatic  model  and  the  wave 
propagation  model.  The  architecture  for  the 
electrostatic  model  was  shown  to  provide 
multiple,  alternative,  near-optimal  solution 
paths.  The  wave  propagation  model  was  shown  to 
solve  the  optimal  path  problem.  Its  neural 
network  architecture  was  shown  to  compute  the 
propagation  of  wavefronts  by  least  cost 
propagation. 

The  partial  differential  equations  were  mapped 
onto  the  massively  parallel  architecture  using 
finite  difference  approximations.  The  numerical 
solutions  of  the  approximation  formulas 
effectively  simulated  the  analog  compuution  of 
Nature.  An  architecture  was  designed  to 
compute  a  five-point  finite  difference 
approximation  solution  to  these  equations.  The 
five-point  finite  difference  approximation 
formula  provided  for  the  definition  of 
interconnection  weights  in  the  architecture. 

The  massively  parallel  computing  architecture 
was  defined  using  explicit  states  of  the  problem 
as  the  computing  nodes.  This  architecture 
computed  solutions  by  exchanging  information 
along  interconnections  defined  in  a  mesh 
topology.  As  this  exchange  continued,  each 
node's  output  converged  to  a  value  which 
represented  the  corresponding  state's  value  in 
the  problem  solution.  These  state  outputs  were 
the  scalar  potential  field  solution  to  the  partial 
differential  equation.  The  approximation 
templates  for  the  finite  difference  formula 
defined  the  interconnection  weights  for  the 
particular  architecture  configuration.  The 
significance  of  this  design  was  a  neuron 
transfer  function  and  weight  formulas  for 
computing  the  finite  difference  approximation. 

This  research  has  shown  the  use  of  the  natural 
parallelism  paradigm  to  solve  trajectory 
generation.  Artificial  neural  networks  were 
designed  using  the  natural  parallelism  concept 
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and  shown  to  provide  good  path  solutions  which 
correspond  to  natural  analogies  of 
electromagnetic  field  theory. 
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Discussion 


1.  R.Klemm,  Germany 

Can  you  give  some  indication  on  how  operational  scenarios 
can  be  fed  into  your  system?  Do  you  consider  optical 
techniques  for  parallel  computing? 

Author: 

Scenarios  begin  with  three  elements.  The  current  turcraft 
location  in  state  space,  and  desired  goal  location  in  state 
space,  and  the  cost  function  for  the  state  space  which 
includes  the  threat  laydown  and  effects  of  terrain  making.  As 
the  aircraft  flies  the  trajectory,  updates  to  these  three 
elements  cause  new  trajectories  to  be  generated  by  the 
system.  Dynamics  of  tiie  environment  can  be  treated 
through  a  fast-time  prediction  using  the  system  interactively 
with  cost  function  updates  according  to  the  threat  dynamics 
model.  We  plan  to  investigate  optical  techiuques  this  year  as 
part  of  our  efforts  to  develop  a  physical  prototype  device. 

2.  D.  Bosnian,  Netherlands 

With  electric  field  equation  model,  trajectories  are 
orthogonal  giving  iso-potential  lines.  In  the  physics  analogy 
no  work  is  involved  in  travelling  along  iso-potential  lines. 
Does  travelling  in  that  direction  involve  accumulated 
danger?  Does  piece-wise  selection  of  iso-potential 
trajectory  parts  provide  acceptable  alternative  trajectories 
not  calculated  by  the  analogy? 

Author; 

Yes.  Danger  is  accumulated  along  any  path,  including  Iso¬ 
potential  curves.  This  is  unlike  physics,  where  no  work  is 
performed.  However,  in  the  physics  analogy,  resistivity  is 
accumulated  along  the  paths  (infinitesimally)  as  is  the 
danger.  No.  Iso-potential  parts  of  trajectories  would  not 
provide  relief  from  danger.  Unlike  work,  where  all  the 
current  paths  are  equivalent  in  that  they  have  the  same  end 
point  potentials,  these  danger  paths  have  unique 
accumulated  danger.  This  is  analogous  to  Ohm's  law,  since 
the  current  density  field  varies  according  to  the  resistivity, 

3.  G.L.  Cohill,  United  States 

Is  the  model  described  in  the  paper  a  constant  velocity 
model?  How  would  you  accommodate  a  variable  velocity 
parameter? 

Author; 

Yes.  The  cost  function  is  developed  as  a  rate  of  danger 
divided  by  velocity.  This  results  in  a  cost  measure  along  the 
line  integral  of  the  path.  Thus,  if  velocity  is  constant,  it  can  be 
factored  out  of  the  path  integral.  To  answer  the  second 
question,  I  don’t  know.  Otherwise,  the  velocity  must  be 
specified  at  every  point  in  the  problem  space.  This  will 
incorporate  velocity  locally  in  the  space.  However,  it  won’t 
guarantee  a  smooth  velocity  profile  over  the  path  itself.  This 
requires  the  development  of  other  ways  to  incorporate 
constraints  into  the  system. 


Il-I 
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Introduction 


Ce  document  pr^sente  une  application  des  m^thodes 
"Riseaux  de  Neuroiles"  h  la  classification  automatique  de 
cibles  en  imagerie  infi^-rouge. 

\ 

Cette  function  d^.  classification  est  un  complement  i 
la  chaine  de  trailements  ms  systimes  optroniques  de  detec¬ 
tion  et  de  pistage.  Elle  perniet  d'ameiiorer  les  performances 
globales  du  systdme  d'arme\ 

-  en  limitant  le  taux  de  faussX^  alarmes  et  de  fausses  pistes, 

-  en  apportant  une  aide  a  I’op&rateur  dans  ses  prises  de  de¬ 
cision.  ^ 

Bien  que  le  systeme  de  detwtion  soit  teste  actuelle- 
ment  sur  des  cibles  adriennes  en  vu\  de  1' integration  It  un 
systeme  de  defense  sol-air,  il  est  suffi^mment  general  pour 
pouvoir  s'appliquer  egalement  aux  systeines  air-sol,  air-air, 
ou  e  tout  autre  type  de  systeme  optronique,  de  conduite  de  tir 

ou  de  veille,  en  video  infra-rouge  ou  visibly. 

\ 

Ce  papier  se  propose  d’etudier  tout  d'abord  comment 
peut  s'integrer  un  module  de  classification  automatique  de 
cibles  dans  un  systeme  d'arme,  el  ce  qu'il  peut  Iqj  apporter. 
Puis,  apres  une  description  technique  de  ce  modil(e,  il  pre- 
senlera  les  premiers  rdsultats  obtenus  en  simulatioi^sur  des 
donnees  reelles. 


\ 

1  Module  de  classification  dans  un  systeme  d’df- 
me. 


1.1.  Description  fonctionnelle  d'un  systeme  d'arme,  rdle  de 
r  optronique. 

Certains  systemcs  d'arme,  embarques  ou  non,  sont 
equipes  de  sous-systemes  optroniques.  C'est  le  cas  notam- 
ment  des  systemes  de  defense  sol-air  courte  ponde,  mais 
aussi  des  systemes  air-sol  ou  des  missiles  fibro-guides. 

Ces  equipemenis  assureni  les  fonctions  de  detection, 
d'acquisilion  el  de  poursuile  (ou  d'accrochage)  de  cible(s). 
C’est  la  localisation  de  la  cible  qui  permet  le  guidage  du  mis¬ 
sile  jusqu'i  r interception. 

En  ce  qui  conceme  le  sous-iysteme  optronique,  ces 
fonctions  sont  generalement  meneet  i  bien  par  des  techni¬ 
ques  de  traitement  d’ Image.  Ces  techniques  sont  nombreuses 
el  efficaces.  Citons  des  algorithmes  fondes  sur  la  detection 
de  contraste,  1’ analyse  du  mouvement  ou  encore  la  correla¬ 
tion  de  zones  d'images. 

L'operateur  recoit  en  tamps  reel  la  visualisation  des  scenes 
observees  par  les  scnsenrs  (Infra-rouge  ou  visible),  sur  la- 
quelle  sont  incrustes  : 

-  la  mire  de  visde, 

-  la  (les)  fenetre(s)  de  poursuite. 

Il  peut  intervenir  pour  ; 

-  aider  I' acquisition,  par  pointage  manual. 


-  valider  ou  inhiber  une  poursuite, 

-  prendre  la  decision  de  tirer. 

1.2.  Rfile  du  systeme  automatique  de  classification  de  ci¬ 
bles. 

Dans  des  environnements  difficiles  :  fond  tres  brui- 
tes,  attaque  saturante,  contre-mesures  (leurres  IR),  incen- 
dies . les  systemes  automatiques  risquent  d'une  part  d’e¬ 

tre  satures  (trop  de  cibles  potentielKs)  et  d’autre  part  de  sur- 
charger  l'operateur  (trop  d ' informations  et  de  demandes  de 
validation) .  Le  i61e  d'un  systeme  de  classification  automati¬ 
que  et  d’aide  k  la  decision  est  de  pallier  k  ces  inconvenients. 

La  classification  s’effectue  k  deux  niveaux.  Au  pre¬ 
mier  niveau,  les  cibles  potentielles  sont  classees  en  terme  de 
"cible”  ou  "fausse  alarme”.  Les  fausses  alarmes  correspon¬ 
dent  aux  leurres  IR,  constructions,  elements  de  fond,  etc. 
Cette  premiere  classification  permet  de  rdduire  le  taux  de 
fausses  pistes  et  allege  ainsi  la  teche  de  l'operateur  et  la 
charge  de  calcul.  Au  deuxieme  niveau,  la  classification  est 
effectuee  sur  les  elements  de  la  classe  "cible”  et  permet  de 
caracteriser  leur  categorie  (avion,  heUcoptere,  missile).  Cet¬ 
te  deuxieme  classification  permet  : 

-  d’ adapter  les  algorithmes  de  pistage  en  consequence, 

-  de  donner  une  priorite  k  cheque  cible  poursuivie, 

-  de  contribuer  e  revaluation  de  la  menace, 

-  d’ aider  k  revaluation  de  la  qualite  d’ interception. 

II  Description  technique. 

2.1.  Methode  neuronale. 

Une  methode  neuromUe  est  une  methode  basde  sur 
I'apprentlssage. 

Les  donnees  d'apprentissage  preiment  ici  la  forme 
d'lQiagettes  qui  segmentent  la  cible  presumde.  Elies  doivent 
etre 'extraites  automatiquement  du  systdme  de  poursuite  de 
facon'4  dtre  operalionnelles.  Ces  imagettes  correspondent  en 
fait  aui^  alarmes  detectdes  par  le  sous-systdme  optronique  de 
poursuite. 

Un  nombre  important  de  doimdes  d'apprentissage  est 
ndcessaire  :  typiquement  plusieurs  dizaines  de  milliers.  Il 
faui,  dans  la  mesure  du  possible,  que  toutes  les  conflgura- 
tions  et  preseiitations  possibles  de  cibles  et  de  fausses  alar¬ 
mes  susceptible^  d’etre  rencontrdes  en  phase  opdrationnelle 
soient  reprdsent^es  dans  I'espace  d'apprentissage.  Si,  par 
example,  I'espace  d'apprentissage  ne  contient  pas  d'oi- 
seaux,  U  est  probable  qu'en  phase  d’ execution,  le  systime 
les  classe  comme  deS  avions  I 

Le  rdseau  de  netirones  prdsentd  ci-dessous  est  inca¬ 
pable  d'Inventer  ce  qu'il  41'a  jamais  vu  ainsi  que  d'diaborer 
des  taisoimements  complie[uds,  il  apprend  au  contraire  par 
I'exemple,  de  facon  tout  k  )^t  empirique. 

En  phase  d’ execution;  le  reseau  de  neurones  recoit 
en  entree  une  imagette  provenhnt  du  sous-systeme  optroni¬ 
que  de  pistage  et  rend  en  sortie  le  code  de  la  classe  reconnue. 
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2.2.  Roseau  de  classiflcation  de  cibles. 
2.2.1.  Structure  du  rdseau. 


rdponse  du  systime  &  la  classe  correspondante.  La  classe  s<- 
lectionnie  eat  celle  qui  donne  la  riponse  la  plus  forte. 


Les  imagettes  recues  en  entrde  par  le  rdseau  sont  tout 
d'abord  prd-traitdes  de  facon  i  leur  donner  une  dimension 
fixe  :  32*32  pixels  (fig.  3). 


Le  rdseau  comporte  quatre  couches  entiirement  inter- 
connecties  (fig.  1)  : 

-  la  couche  d’entrde  correspond  aux  pixels  de  1' image  k  re- 
connattre.  Elle  forme  un  vecteur  X  de  dimension  1024; 

-  le  vecteur  Y  correspondent  &  la  premiire  couche  cachde 
est  de  dimension  100; 

-  le  vecteur  Z  (seconde  couche  cachde)  est  de  dimension 
30; 

-  le  vecteur  T  (couche  de  sortie)  est  de  dimension  4.  Les 
coordonndes  du  vecteur  de  sortie  correspondent  aux  diffdren- 
tes  classes  possibles  (dans  notre  cas  :  cible  en  limite  de  por- 
tde,  hdlicoptdre,  avion,  construction). 

Les  coordonndes  de  ces  vecteurs  sont  appeldes  les 
"neurones"  et  sont  des  petits  processeurs  dldmentaires.  Les 
"neurones"  d'une  couche  sont  connectds  k  ceux  de  la  couche 
suivante  par  des  "synapses",  qui  sont  en  fait  des  coefficients 
de  transmission.  Ces  coefficients  (il  y  en  a  ici  plus  de  100 
000),  forment  les  matrices  A,  B  et  C  (fig.  1).  Toute  r"intel- 
ligence"  du  systime  se  trouve  dans  la  valeur  de  ces  coeffi¬ 
cients. 


unresolved 

urget 

hcUcopicr 

plane 

construction 


(fig.  1) 


Le  classement  revient  k  effectuer  les  opdrations  sui- 
vantes  : 

Y  «  f(A.X) 

Z  =  f(B.Y) 

T  »  f(C.Z) 

oO  f  est  une  fonction  de  seuUlage  (fig.  2) . 

Chacune  des  coordonndes  du  vecteur  T  reprdsente  la 


f(x) 


r  impldmentation  hard  temps  rdel  de  ces  multiplica¬ 
tions  vecteur-matrice  est  d’autant  plus  rdalisable  que  les  di¬ 
mensions  des  diffdrentes  matrices  sont  faibles. 


2.2.2.  Phase  d’apprentissage  automatique. 

La  phase  d'apprentissage  a  pour  rble  le  calcul  de  ses 
coefficients  synaptiques  ; 

II  est  notamment  important  de  minimiser  le  nombre 
de  coefficients  ndeessaires  pour  faciliter  la  rdalisation  matd- 
rielle,  tout  en  en  gardant  une  quantitd  suffisante  pour  que  les 
performances  du  systdme  de  classification  soient  optimales. 

Les  premiers  essais  d’apprentissage  utilisant  I'algo- 
rithme  de  la  retro-propagation  du  gradient  ont  donnds  des 
rdsultats  encourageants  mais  pas  excellent  (80%  de  bonnes 
reconnaissance).  Une  amdlioration  des  performances  a  dtd 
obtenue  en  proeddant  en  deux  dtapes  de  la  manidre  suivante: 

a-  Premidre  dtape  : 

Elle  est  destinde  a  aider  la  seconde  et  la  rendre  plus  perfor- 
mante.  Elle  consisle  k  regrouper  les  imagettes  de  I'espace 
d'apprentissage  topologiquement  proches  (e’est  k  dire  :  qui 
se  ressemblent)  et  de  mdme  classe,  en  "nuages"  lindairement 
sdparables  deux  k  deux.  Ce  regroupement  en  nuages  s'ob- 
tient  automatiquement  par  un  rdseau  de  type  Kohonen  (algo- 
rithme  proche  de  celui  des  nudes  dynamiques). 

b-  Seconde  dtape  : 

Elle  est  chargde  du  calcul  proprement  dit  des  coeffi¬ 
cients  synaptiques.  La  premidre  dtape  permet  de  dormer  une 
signification  prdcise  d  chacun  des  neurones  des  couches  ca- 
chdes,  et  de  guider  I'apprentissage.  En  effet  cheque  neurone 
de  la  premidre  couche  cachde  est  spdciallsd  dans  la  sdpara- 
Uon  des  imagettes  de  deux  nuages  donnds,  les  neurones  de  la 
seconde  couche  cachde  correspondent  aux  nuages,  et  les 
neurones  de  la  couche  de  sortie,  aux  classes.  L’apprentissa- 
ge  se  fait  par  retro-propagation  du  gradient  couche  par  cou¬ 
che.  Le  systdme  cherche  done  k  reconnaltre  le  "nuage"  au- 
quel  appartient  une  imagette  avant  d'en  dddutre  sa  classe. 
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Un  simple  perceptron  it  une  couche  et  une  sortie  pei- 
met  en  effet  de  sdparer  avec  de  tr£s  bonnes  performances 
tant  en  apprentissage  qu'en  gdndralisation  deux  imagettes 
appartenant  k  deux  nuages  donndes.  Ce  probldme  est  nette- 
ment  moins  complexe  que  le  problime  global  de  classifica¬ 
tion  k  rdsoudre  car  les  donndes  k  sdparer  sont  topologique- 
ment  regroupdes  de  facon  cohdrente,  et  sont  Undaiiement  sd- 
parables  alors  que  les  donndes  du  probldme  total  sont  forte- 
ment  mdlangdes  et  dispersdes.  Les  performances  du  percep¬ 
tron  par  rapport  au  probldme  simple  ne  sont  limitds  que  par 
le  caractdre  plus  ou  moins  flou  des  frontidres  sdparant  les 
nuages. 

P^prds  avoir  ddcomposd  I'espace  d' apprentissage  en 
sous-ensembles  cohdrents,  le  probldme  global  de  classifica¬ 
tion  pent  se  ddcomposer  en  un  grand  nombre  de  probldmes 
moins  complexes  que  Ton  salt  rdsoudre  avec  de  bonnes  per¬ 
formances. 

Les  rdponses  de  tous  ces  perceptrons  (il  y  en  d  plus 
d'une  centaine)  forment  la  premidre  couche  cachde  du  rd- 
seau  (le  vecteur  Y).  11  serait  possible  de  ddduire  formelle- 
ment  la  classe  d*un  objet  de  facon  logique  et  statistique  k 
partir  de  ces  rdponses.  Nous  prdfdrons  toutefois  rdsoudre  ce 
probldme  par  apprentissage  neuronal  de  facon  k  mieux  tenir 
compte  des  valeurs  rdelles  prises  par  chacun  des  neurones  du 
vecteur  V.  Nous  apprenons  ainsi  au  systdme,  par  I'algorith- 
me  de  rdtro-propagation  du  gradient,  de  ddduire  du  vecteur  Y 
le  nuage  d’appartenance  de  I'imagette  (le  vecteur  Z),  puis 
enfin  sa  classe  (le  vecteur  T). 

Nous  remartpions  que  seule  la  premidre  couche  de  sy¬ 
napses  travaille  sur  des  donndes  brutes.  Ces  synapses  con¬ 
vergent  vers  des  valeurs  nuancdes  et  non  saturantes.  Par  cen¬ 
tre  les  autres  couches  synaptiques  ne  travaillent  que  sur  des 
doimdes  symboliques.  Ces  synapses  convergent,  eux,  vers 
des  valeurs  beaucoup  plus  saturantes  (-1  ou  +1)  ou  neutres 
(0). 

Ces  algotithmes  d' apprentissage  soot  actuellement 
impldmenlds  sur  une  station  de  travail  SUN  4,  et  toument  en 
temps  diffdrd  sur  des  bases  de  donndes  rdelles  extraites  de 
notre  bibliothdque  de  viddos  infra-rouges. 


2.2.2.  Phase  d’exdcution. 

L'algorithme  de  la  phase  d'exdcution  est  beaucoup 
plus  simple  que  ceux  de  la  phase  d' apprentissage.  Le  but 
dtait  en  effet  d' avoir  en  phase  d'exdcution  un  procddd  facile 
d  impldmenter  en  temps  rdel  alors  que  1' apprentissage  pou- 
vait  s'effectuer  en  temps  diffdrd  en  laboratoire  une  fois  pour 


routes. 

II  s'agit  dans  un  premier  temps  d' interfacet  le  systd¬ 
me  neuronal  k  un  systdme  de  poursuite.  cette  interface  doit 
dtre  capable  de  foumir  en  temps  rdel  au  rdseau  les  imagettes 
sdlectionndes,  au  format  32*32.  II  est  pour  cela  ndcessaire 
d’impldmenter  un  algorithme  de  zoom  /  ddzoom  adaptatif.  II 
n'y  a  pas  ndcessitd  d'impidmenter  un  algorithme  trds  sophis- 
tiqud  :  du  moment  que  les  imagettes  de  I'espace  d' apprentis¬ 
sage  ont  dtd  mise  au  format  par  le  mdme  algorithme,  le  sys¬ 
tdme  neuronal  pent  supporter  des  distortions  importantes. 

Puis,  la  phase  d'exdcution  proprement  dite  du  classi- 
fieur  consiste  k  effectuer  I'opdration  :  T  =  f(C.f(B.f(A.X))). 
II  s'agit  de  trois  multiplications  vecteur-matrice  et  1' applica¬ 
tion  de  trois  fonctions  de  seuillage  (sigmoide) .  Les  multipli¬ 
cation  vecteur-matrice  peuvent  s' impldmenter  efficacement 
sur  un  processeur  de  traitement  du  signal  de  type  DSP,  les 
seuillages  peuvent  s' impldmenter  sous  la  forme  d'une  table 
de  convertion. 


Ill  Premiers  rdsultats  obtenus  en  simulation  sur 
des  donndes  rdelles. 


Les  performances  obtenues  quant  d  la  discrimination 
cible  /  fausse  alarme  sont  de  I'ordre  de  9S%  sur  tout  type  de 
cibles  ou  de  b&timents,  quelles  que  soient  leur  prdsentation  et 
leur  dloignement,  sur  fond  de  terre,  de  ciel  ou  de  mer.  Les 
bases  d'apprentisso—  utilisdes  component  plusieurs  milliers 
d’ imagettes. 

II  reste  toutefois  k  valider  le  procddd  opdrationnelle- 
ment,  sur  une  diversitd  encore  plus  grande  de  configurations. 

Conclusion 


Les  rdsultats  obtenus  sur  des  donndes  rdelles  mon- 
trent  I'intdrCt  des  mdtbodes  neuronales  pour  la  classification 
de  cibles  en  optronique.  Une  maquette  (temps  rdel)  de  cette 
fonction  est  en  cours  de  rdalisation,  elle  sera  prochainement 
intdgrde  dans  un  systdme  de  poursuite  automatique. 

Cette  approche  "Rdseaux  de  Neurones”  peut  dtre 
dtendue  aux  dquipements  ndcessitant  une  classification  ou 
une  reconnaissance  automatique  des  cibles  k  atteindre  dans 
un  environnement  complexe. 

Ces  mdtbodes  fonddes  sur  1' apprentissage  constituent 
une  avancde  pour  les  systdmes  futurs,  ''intelligents”,  dotds  de 
vision  artificielle  et  de  capacitd  de  ddcision. 
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Discussion 


1.  Jeff  Grinsluiw,  United  States 

Was  testing  done  on  the  training  set? 

Author 

No,  of  course  testing  was  done  on  a  testing  set  that  was 
different  than  the  training  set. 

2.  Jeff  Grinshaw,  United  States 

Similar  work  is  being  conducted  at  the  Air  Force  Institute  of 
Technology  (Am  ),  United  States.  They  use  pre-processing 
of  the  pixel  data.  Have  you  considered  using  pre-processing, 
or  is  it  not  necessary? 

Author. 

Pre-processing  of  the  pixel  is  certainly  not  a  necessity 
because  it  works  without  pre-processing,  and  it  does  it  very 
well,  and  humans  do  not  use  pre-processing  which  is  not 
neural  pre-processing.  But  it  is  not  forbidden  to  use  pre¬ 
processing,  it  can  just  be  more  complicated.  Most  of 
pre-processing  can  be  implemented  into  a  neural  network 
(with  local  connections  for  example). 

3.  D.  Bosnian,  Netherlands 

To  a  Region  of  Interest  (ROI)  of  1024  pixels,  usually  very 
little  pixels  contribute  to  the  recognition  process.  In  a  1000- 
dimensional  space  each  aspect  of  every  object  occupies  a 
cloud  which  must  not  interfere  with  neighboring  clouds;  if 


so,  uncertainty  results.  You  stated  that  the  system  was 
trained  on  5000  objects.  How  many  aspect/object  clouds 
can  be  safely  (at  P%  probability  of  confidence)  stored  in  the 
Ik  dimensional  space?  Is  Che  amount  of  5000  mentioned, 
given  the  large  volume  of  the  clouds  because  little  numbers 
of  pixels  participate  in  the  recognition,  already  overstraining 
available  capacity? 

Author: 

In  fact  the  1024  pixels  contribute  to  the  recognition  process 
and  not  only  a  very  few  of  them.  But  as  they  are  linked 
together,  in  fact,  they  can  be  compressed.  The  low  number  of 
“Clouds”  needed  is  due  to  the  fact  there  is  a  high  possible 
compression  rate.  The  way  to  compress  the  information  to 
very  few  symbolic  elements  which  are  the  classes  to 
recognize,  is  the  aim  of  the  neural  learning  process. 

4.  Glenn  Johnson,  United  States 

How  does  the  system  handle  scaling  of  the  image  size?  Does 
the  system  require  retraining  for  images  of  different  sizes? 
Does  not  this  make  for  a  very  large  training  set? 

Author: 

There  is  no  pre-processing  except  that  subimages  are 
extracted  and  formatted  into  the  52  X  32  pixel  format.  The 
identifier  must  be  trained  to  recognize  these  scalings  of  the 
image,  only  in  the  sense  that  scaling  of,  for  example,  6  pixel 
image  has  less  detail  than  scaling  of  12  pixel  image. 
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THREAT  LOCALIZATION 
A  major  breakthrough  for  Intelligent  E.W.  Systems 


C.  MAILLARD 

DASSAULT  ELECTRONIQUE  (D.E.) 
S5»  quai  Marcel  Dassault 
92214  Saint-Cloud 
Prance 


BLANCHE  1  :  THREAT  LOCAUZATION 

La  survie  (survivability)  d'un  avion  de 
combat  modeme  est  tris  li4e  k  sa  capacity 
k  determiner  la  situation  tactique  pr4ci- 
s4ment»  en  temps  r4eL 

Nous  allons  montrer  I'impact  de  la  locali¬ 
sation  des  menaces  sur  1*  ’’intelligence”  des 
syst4mes  de  contremesures. 

Auparavant,  nous  souhaitons  vous  presenter 
DASSAULT  ELECTRONIQUE  (D.E.). 


BLANCHE  2 :  SOFTWARE 

En  ce  qui  concerne  les  capacites  en  logiciel 
de  D.E.  i 

-  850  specialistes  logiciel, 

-  creation  d'une  filiale  "DE3I"  avec  IBM, 

-  9  ordinateurs  centraux,  et  plus  de  4  000 
terminaux. 

Enfin,  D.E.  prend  place  parmi  les  leaders  en 
Intelligence  Artificielle.  Grftce  4  une  solide 
experience  de  plus  de  10  ans,  D.E.  a,  en 
utilisant  les  techniques  de  I'Intelligence 
Artificielle,  developpe  et  mis  au  point 
nombre  d'outils  qui  ont  perm  is  de  realiser 
differentes  applications  et  d'aboutir  4  des 
produits. 

Ces  techniques  et  outils  gOneraux  sont : 

-  une  methodologie  de  dOveloppement  de 
Syst4mes  Experts  :  MEDIUS,  en 
complement  de  la  methodologie  de 
developpement  de  logiciel  MINERVE, 

-  le  langage  PROLOG,  et  surtout  le 
developpement  (PEMICAT,  extension  de 
PROLOG  vers  un  langage  oriente  objet 
permettant  I'aoquisltion  de  connaissance 
complexes  griee  4  des  mecanismes  de 


"frame”,  d'heritages,  de  reflexes  et  de 
regies  de  production. 

EMICAT  est  distribue  mondialement  par 

IBM  sous  le  nom  d'lPW  : 

-  la  participation  4  NESTOR  EUROPE 
dans  le  domaine  des  reseaux 
neuromimetiques ; 

-  I'utilisation  de  VISILOG  pour  les  etudes 
et  les  developpements  de  projets  en 
traitement  d'images. 


BLANCHE  3  ;  A  J.  ABBUCATIONS 

Les  applications  realisees  chez  D.E. 

couvrent  de  nombreux  domaines  : 

-  I’aide  logicielle  integree  pour  IMnforma- 
tique  documentaire, 

-  I'aide  au  diagnostic  technique  (CATS 
pour  les  circuits  analogiques  4  base  de 
modeies,  GIBUS  utilise  operation- 
nellement  pour  la  gestion  des  batteries 
de  satellites), 

-  I'aide  4  la  decision  et  I'aide  au  comman- 
dement  (generation  de  scenarios  de 
deplacement  d’armee  :  PEGASE  et 
simulation  de  la  bataille  aeroterrestre  : 
CARNEADE), 

-  la  synth4se  logique  de  circuits  integres 
speficiques  (ASICs) :  FRENCHIP. 
FRENCHIP  est  commercialise  sous 
UNIX. 

-  I'aide  4  Sexploitation  de  satellites 
(systems  de  contrdle  et  de  commands  de 
satellite  SATEXPBRT) 

-  DASSAULT  ELECTRONIQUE  effeetue 
de  nombreuses  recherches  dans  le 
domaine  de  I'Intelligence  Artificielle  en 
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temps  riel  :  un  systime  expert  tempe 
riel  vous  sera  prisenti  en  ditail  par 
Monsieur  SERVBL  de  D.E.  (confirence 
n*  18). 

Enfin,  ie  systime  d'identification  de 
menaces  SEISMEt  avec  de  fortes 
contraintes  sur  le  temps  de  riponse,  est  le 
coeur  de  ce  papier. 

Avant  de  cemer  I'impact  de  I'l.A.  sur  lea 
systimes  ilectroniques  de  difense,  il  faut 
commencer  par  difinir  les  besoins 
opirationnels  en  autoprotection. 


PLANCHB  4  ;  FUTURE  RWR  REOUI- 

REMENTS 

L'ivoiution  des  menaces  est  caractirisie 

par : 

-  leur  agiliti, 

-  leur  mobilitit 

-  leur  diversiti, 

-  leur  densiti. 

*  Contre  I'agiliti  des  paramitres 
(friguence»  PRF,  PW,  ...),  une  meaure 
tris  priciM  de  la  direction  d'arrivie 
(DO  A)  est  essentielle  :  la  DO  A  est  le 
meilleur  paramitre  de  tri,  car  le  seui 
stable  dans  le  temps. 

*  Les  autres  caractiristiques  des  menaces 
rendront  leur  tri  et  leur  identification 
de  plus  en  plus  difficile.  II  est  done 
nicessaire  d'amillorer  les  capteursy  et 
bien  sQr  le  traitement. 


PLANCHE  5  :  RWR  BLOCK  DIAGRAM 

Pour  faire  face  k  l'ivoiution  des  menaces^ 
une  architecture  du  type  prisenti  sur  la 
planehe  eat  nicessaire.  Outre  les  capteurs 
"elasalques",  des  capteurs  de  nouvelle 
giniration  Onterfiromitre  large  bande 
instantanie,  IFM,  Analyse  spectrale  temps- 
riel)  seront  intigris  au  niveau  de 
I'impulslon  pour  obtenir  un  temps  de 
riponse  suffteamment  court  pour  envisager 
les  actions  adiquates  (brouillage,  leurrage, 
ivasive,  ARM* ...). 


PLANCHE  9  i  ItKiftzatlan  arinetalm 

De  plus,  la  mesure  pricise  de  I'angle 
d'arrivie  (DOA),  (typiquement  10  fois 
meilleure  que  celle  des  iquipements 
standard)  essentielle  pour  le  tri  et  le  di- 
entrelaeementt  permet  aussi  de  localiser 
giographiquement  les  imetteurs  de  maniire 
passive,  grice  au  principe  de  triangulation 
diji  dimontri  sur  les  iquipements  ESM. 


PLANCHE  7  :  Optrational  aOvantaat* 

Les  avantages  opirationnels  de  la  locali¬ 
sation  des  menaces  sont  tris  nombreuz,  et 
augmentent  considirablement  les  capacitis 
opirationnelles  de  I'avion. 

De  nombreuses  notions  font  appel  i  un 
traitement  intelligent  :  corrilation  tactique 
de  menaces,  ordres  d'ivitement  de  la 
menace  la  plus  dangereuse,  caleul  de 
prioriti,  et  bien  sOr  amilioration  de 
I'identification  des  menaces  (ESM).  Mais 
comment  faire  ? 


PLANCHE  a  :  PILOT  INTERFACE 

Le  pilote  a  besoin  d'une  interface  claire, 
pricise  et  done  synthitique.  La  localisation 
des  menaces  et  un  traitement  intelligent, 
sont  essentiels  pour  satisfaire  ce  besoin. 


PLANCHE  9  PRnrFSSING 

Le  traitement  nicessaire  est  dicrit  sur 
cette  planehe  pour  ilaborer  la  situation 
tactique  en  temps  riel : 

-  capteurs  mesurant  entre  autres  la 
direction  d'arrivie  (DOA)  des  menaces 
avec  une  grande  pricision, 

-  une  corrilation  impulsion  par  impulsion 
entre  capteurs,  basie  sur  le  temps 
d'arrivie  des  impulsions, 

-  un  pri-filtrage,  utilisant  une  matrice  de 
comparateurs  i  fenitre  (Window 
Addressable  Memory)  qui  permet  de 
riduire  considirablement  le  flot  de 
donnies  par  > 
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.  la  reconnaissance  des  plots  pris 
en  compte  (disentrelacement,  ...)t 

.  la  mlse  en  Evidence,  tria  rapi- 
dement,  de  tout  changement  de 
I'environnement  (nouvelle  menace, 
changement  ou  Evolution  des 
paramitres  d'une  menace), 

-  un  processeur  pour  la  localisation  des 
menaces, 

-  et  un  calculateur  de  haut  niveau  (PMF) 
pour  I'identification,  utilisant  des 
techniques  d'lA  que  nous  allons 
d4velopper. 

Les  deux  id4es  importantes  sont  les  "feed¬ 
backs”  qui  permettent : 

-  de  positionner  les  valeurs  minimum  et 
maximum  du  pr4-filtrage  k  partir  des 
r4auitats  de  la  localisation, 

-  de  modifier  les  capteurs  en  fonction  des 
r4sultats  d'identification  (en  cas 
d'ambigulit4  par  example). 


BLANCHE  10  :  PRE-FILTERING 

Ce  tableau  resume  tr4s  sch4matiquement 
trois  approches  possibles  pour  le  pr4- 
filtrage : 

-  approche  ”classique", 

-  approche  par  "Window  Addressable 
Memory"  (WAM),  retenue  par  D.E,, 

-  approche  par  syst4mes  neuronaux. 

Des  conferences  sont  pr4vues  lors  de  ce 
symposium  sur  ce  point  particulier. 

Nous  pensons,  suite  aux  recherches 
effectu4es,  que  le  pr4-filtrage  est  une 
bonne  application  possible  k  terme  pour  les 
syst4mea  neuronaux,  mais  il  faudra  r4soudre 
les  difficult4s  li4es  k  l'int4gration  du  temps 
(PRF,  sequences. 


BLANCHE  U  :  PHOfTO 


BLANCHE  12  :  AJ.  Three! 

Cette  longue  introduction  etait  necessaire 
pour  bien  situer  le  probl4me  lie  k 
I'identification  des  menaces.  ' 

En  resume,  I'evolution  des  menaces  conduit 
e  la  necessite  d'ameiiorer  leur  analyse  t 

-  analyse  spatiale, 

-  analyse  temporelle, 

-  et  bien  sfir,  mesures  des  pararndtres 
eiectromagnetiques  (RF). 

En  conclusion,  une  description  "intelligente" 
de  la  menace  est  necessaire,  et  doit  etre 
utilisee. 


BLANCHE  13  :  SEBUE 

Le  systeme  Expert  "SEISME"  eiabore  la 
situation  tactique  en  temps  reeU 

Les  axes  de  recherche  pour  ce  Systeme 
Expert  sont : 

-  modeiisation, 

-  raisonnement  dans  un  monde  imprecis  et 
ineomplet, 

-  resolution  d'ambiguYte, 

-  determination  des  heuristiques  neces- 
saires, 

-  evaluation  de  la  validite  de  la  situation 
tactique  eiaboree, 

-  reprogrammation  pour  reconfigurer  le 
systeme. 

Le  but  de  SEISME  a  ete  d'appliquer  ces 
techniques  au  problems  de  I'identification, 
avec  des  contraintes  en  temps  reel. 


BLANCHE  14  :  ARCHTTECTURE 

L'architecture  retenue  est  decrite  sur  la 
planche. 

On  notera : 

-  les  pistes  (Tracks)  provenant  du  pre- 
filtrage, 

-  les  fishes  (Forms)  techniques, 

-  les  phases  (Phases)  temporelles, 

-  les  psrametres  du  systems  expert. 
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L«  rftniltait  est  I'identification  des  menaces 
quasi  an  temps  rdeL 


PLANCHE  IS :  DBCRIPTIDN 

La  definition  de  cheque  terroe  eat  precisee 
sur  cette  planche. 

A  noter  qu'une  piste  est  conaituee  des 
positions  angulaires,  distance  ainsi  que  des 
parametres  ElectroMagnetiques  E.M.  (RF). 


PLANCHE  16  t  IDENTIFICATION 

La  cie  d'une  bonne  identification  est  la 
separation  entre  les  caracteriatiques 
geographiques  et  eiectromagnetiques. 

Cette  discrimination  spatiale  est 
essentielie. 

Un  "mapping"  eat  effectue  en  cas  de  non¬ 
discrimination  spatiale  entre  les  pistes  RF 
et  les  f  iches. 

Enauite,  une  association  instantanee  est 
effectude,  basee : 

-  sur  la  correspondance  (agreement)  du 
mapping, 

-  sur  le  nombre  de  menaces  identifiees, 

-  sur  le  nombre  de  fiches  manquantes  pour 
les  menaces  identifiees. 

Des  heuristiques  sont  neccssaires  pour 
maUriser  i'expiosion  combinatoire  resultant 
de  I'association  possible  de  plusieurs 
menaces  pour  cheque  fiche. 


PLANCHE  IT  :  HBURETICS 

L'idee  est  (Peffectuer  un  partitionnement  du 
probieme,  ear  t 

-  I'intarpretation  de  quelques  pistes  est 
independantes  (fautres  pistes, 

-  peu  de  pistes  evoiuent  en  fonetion  du 
temps  (I'angie  tfarrivee  (DOA)  evolue 
trda  lentemant  en  fonetion  du  temps). 

Css  evolutions  sont  detsetees  griee  au  pre- 
filtrage. 


-»  On  ne  traite  done  que  les  partitions 
evoluants. 

-»  L'influence  de  la  precision  sur  la  DOA 
est  capitale  sur  ee  partitionnement, 
comme  le  suggere  le  schema  :  il  vaut 
mieux  5  probiemes  independants  de 
niveau  simple  que  2  probiemes  de  niveau 
tres  complexes. 


PLANCHE  18  :  MESA 

Le  but  essentiel  de  SEISME  eat  de  valider 
I'apport  des  techniques  d'intelligence 
artificielle  pour  evaluation  de  la  situation 
tactique  (identification,  calcul  de  priorite, 
...) 

Ce  systeme  expert  a  done  ete  couple  au 
simulateur  MESA  ("Modeiisation  et 
Evaluation  des  Systemes  d'Autoprotection”) 
qui  permet  de  simuler  les  conditions 
operationnelles,  en  particulier  en  tenant 
compte  des  relations,  liens  entre  menaces 
et  de  leur  caractere  "reactif,  ainsi  bien  sQr 
que  la  modeiisation  du  systeme 
d'autoprotection  (precision  sur  la  Direction 
d'Arrivee  (DOA  accuracy),  precision  de 
localisation, ...). 


PLANCHE  19  i  SaSIHK 

Nous  avons  done  evalue  les  performances  de 
SEISME  dans  un  environnement  operationnel 
complexe  simuie  par  MESA. 

Nous  avons  aussi  developpe  de  nouveaux 
principes  d'Intellignece  Artificielle. 

Des  extensions  sont  prevues  : 

-  evitement  de  menace, 

-  calcul  de  priorite. 

Enfin,  lea  posslbilites  d'embarquer  ce 
systeme  sont  etudiees  (en  particulier  sur 
une  machine  paralieie  :  Transputer  ou 
machine  RISC). 

En  conclusion,  nous  vons  evalue 
I'importance  relative  des  differents 
criteres :  la  discrimination  angulaire  est 
essentielie  pour  obtenir  un  temps  de 
reponse  sufnsamment  court,  car  elle 


12-? 


permet  de  contrdler  I'explosion  combi- 
natoire. 


PLANCHB  20  :  CONCLUSION 

Les  ameliorations  de  performances  pour 
I'identification  des  menaces  avec  les 
techniques  d'Intelligence  Artificielle  ont 
ete  dimontrees. 

Une  mesure  tr^s  precise  de  I'angle  d'arrivee 
des  menaces  (et  leur  localisation)  est 
essentielle  pour  respecter  les  contraintes  de 
temps  reel. 
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CONCLUSION 


•  PERFORMANCE  IMPROVEMENTS  WITH 
ARTIFICIAL  INTELLIGENCE  PROVEN  FOR 
EMITTER  IDENTIFICATION 

•  ACCURATE  OOA  MEASUREMENT  (AND 
EMITTER  LOCALIZATION)  ESSENTIAL  FOR 
REAL-TIME  REQUIREMENTS 
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A  NASA/RAE  Cooperation  in  the  Development  of  a 
Real-Time  Knowledge  Based  Autopilot 


Cblin  Daysh' 
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Geoff  Butler' 
Eugene  L.  Duke® 
Steven  D.  Belle* 
Randal  W.  Brumbaugh* 


1.  Summary 

As  part  of  a  US/UK  cooperative  aeronailtical 
research  programme,  a  joint  activity  betw«n 
NASA  Ames-Dryden  and  the  Royal  Aero^ce 
Establishment  on  Knowledge  Based  Systems 
(  KBS  )  has  been  established.  This  joint  amvity  is 
concerned  with  tools  and  techniques  for  thmmple- 
mentation  and  validation  of  reaktime  KBS.  This 
paper  describes  the  proposed  next  stage  ofins^—^ 
research,  in  which  some  of  the  problems  of  imple¬ 
menting  and  validating  a  Knowledge-Based  Autopi¬ 
lot  (KBAP)  for  a  generic  high-performance  aircraft 
will  be  investigated. 

2.  Introduction 

The  research  programme  described  in  this  paper 
will  be  the  latest  in  a  longstanding  series  of  colla¬ 
borations  between  the  Dryden  Flight  Research 
Facility  of  the  NASA  Ames  Research  Center  in  the 
USA  and  the  Royal  Aerospace  Establishment 
(  RAE  )  in  the  UK.  Previously,  the  Cooperative 
Advanced  Digital  Research  Experiment  (  CADRE ) 
programme^  was  established  in  1981  to  investigate 
the  applicability  of  non-linear  control  techniques  to 
a  fly-by-wire  aircraft.  Non-linear  control  laws 
developed  at  RAE  were  successfully  fligjtt  tested  on 
the  NASA  F8  digital  fly-by-wire  aircraft  using  the 
Remote  Augmented  Vehicle  (  RAV  )  facility^,  in 
which  ground-based  computers  are  used  to  control 
a  piloted  aircraft  remotely  via  telemetry  links. 


More  recently,  a  collaborative  project  on 
Knowledge  Based  Systems  (  KBS  )  was  under¬ 
taken^  to  investigate  some  of  the  real-time  aspects 
of  applying  such  techniques.  Under  this  pro¬ 
gramme,  a  prototype  Flight  Status  Monitor  for  the 
X-29  research  aircraft,  which  had  been  designed  in 
a  non-real-time  form  by  NASA,  was  re¬ 
implemented  at  RAE  in  the  Muse  real-time  KBS 
language'*’^.  This  gave  a  significant  speed  improve¬ 
ment  over  the  original  and,  though  it  still  fell  some 
way  short  of  full  real-time  operation,  considerable 
insights  were  gained  into  the  requirements  which 
any  real-time  system  wo^d  have  to  meet. 

The  proposed  latest  jM^ramsK^)^  go  further  in 
the  investigation  of  real-time  KBS  system  design. 
Known  informally  as  the  Cooperative  Real-time 
Intelligent  Systems  Program(me)  (  CRISP  ),  it  will 
investigate  the  implementation  and  validation  of  a 
Knowledge  Based  Autopilot  (  KBAP  ).  While  it  is 
recogni.sed  that  this  problem  is  probably  more 
appropriately  tackled  by  conventional  algorithmic 
techniques,  the  KBAP  provides  a  simple,  well- 
defined  yet  real  problem  within  which  to  explore, 
develop,  and  demonstrate  real-time  KBS  concepts 
and  validation  and  verification  techniques  for 
mission-critical  systems.  ^ 

A  prototype  autopilot  has  already  been  imple¬ 
mented  using  the  NASA-developed  KBS  tool 
CLIPS^  However,  this  implementation  was  shown 
to  be  fairiy  slow,  and  hence  inappropriate  for  a 
real-time  flight  control  application.  The  RAE  has 
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developed  the  Fortran  Library  for  EXpert  System 
Development,  FLEX^,  which  has  been  demon¬ 
strated  to  be  an  order  of  magnitude  faster  than 
other  KBS  tools  on  benchmark  problems*.  This 
paper  discusses  the  likely  best  method  of  approach¬ 
ing  the  reimplementation  of  the  CLIPS  autopilot 
rules  in  FLEX  to  produce  a  Knowledge  Based 
Autopilot  which  runs  in  real-time.  Some  prelim¬ 
inary  performance  estimates  are  presented  below, 
based  on  work  done  using  a  generic  ruleset  typical 
of  the  form  likely  to  be  taken  by  the  final  KBAP 
system. 

One  of  the  main  areas  of  interest  in  this  project  is 
to  establish  a  route  by  which  a  system  based  on 
KBS  techniques  could  be  validated  as  fit  for  flight 
NASA  Dryden  have  considerable  experience  in  the 
validation  of  more  conventional  algorithmic  avionic 
systems^''®'''  and  are  keen  to  investigate  ways  of 
extending  these  to  cover  the  more  diffuse  behaviour 
exhibited  by  a  Knowledge  Based  System.  If  the 
work  is  successful,  it  is  hoped  that  the  KBAP 
would  be  flight  tested  in  future  phases  of  the  pro¬ 
ject. 

3.  An  Overview  of  the  KBS  Toolkits 

3.1  CLIPS  Expert  System  Shell 

CLIPS  is  an  expert  system  shell  with  a  LISP-like 
syntax  developed  at  the  NASA  Johnson  Space 
Flight  Centre.  The  basic  elements  of  CLIPS  are;  a 
fact-list,  comprising  global  memory  for  data,  a 
knowledge-base  ctxitaining  all  of  the  rules  and  an 
inference  engitre  which  controls  overall  executioa 

A  programme  written  in  CLIPS  consists  of  rules 
and  facts.  The  inferetKe  engine  decides  which  rules 
should  be  executed.  Basically,  rules  fire  (are  exe¬ 
cuted)  in  much  the  same  way  that  an  IF  THEN 
statement  is  executed  in  a  procedural  language  such 
as  Ada.  That  is,  the  rule  fires  IF  certain  conditions 
are  true,  and  it  THEN  executes  a  set  of  actions. 

The  conditions  that  fire  the  rule  are  facts.  The  rule 
only  fires  if  certain  facts  have  been  asserted  (i.e  the 
fact  exists  and  is  true). 

CLIPS  has  variables  available  in  which  to  store 
values.  This  is  a  very  powerful  tool  which  enhatKes 


the  way  in  which  rules  and  facts  can  be  manipu¬ 
lated.  Variables  in  CLIPS  are  written  in  the  syntax 
of  a  question  mark  followed  by  a  variable  name. 

For  example: 

?x 

?value 

?colour 

?sound 

One  of  the  most  useful,  and  most  powerful  applica¬ 
tions  of  variables  is  in  pattern  matching.  This  is 
where  the  facts  on  the  LHS  of  a  rule  are  partially 
replaced  by  variables.  For  example,  the  rule; 

(defrule  variable-example 
(blue  exterior) 

(?colour  interior) 

=> 

(assert  (interior-colour  ?colour))) 

Will  be  fired  by  the  "blue  exterior",  and  by  any  fact 
which  has  two  fields,  with  the  word  "interior"  as  its 
second  field.  It  will  then  assert  a  fact  that  records 
the  first  field  of  the  second  fact  For  example,  the 
rule  will  be  fired  when  the  following  facts  are 
asserted: 

(blue  exterior) 

(pink  interior) 

The  rule  will  assert  the  fact  (interior-colour  pink). 

Another  useful  feature  of  CLIPS  is  its  ability  to  do 
calculations  within  rules.  Expressions  to  be  calcu¬ 
lated  must  be  written  in  prefix  form,  that  is,  the 
expression  2  -»■  3  would  be  written  (+2  3).  Again 
this  is  where  CLIPS  resembles  LISP.  This  facility 
can  be  used  to  assert  facts,  for  example: 

(assert  (answer  =(+  2  3))) 

would  assert  the  fact  "answer  5".  It  is  possible  to 
use  variables  within  expressions,  for  example: 

(assert  (answer  =(-  ?x  ?y))) 

This  would  calculate  ?x  -  ?y,  using  the  actual 
values  assigned  to  the  variables  ?x  and  ?y,  and  then 
assert  the  fact  to  record  the  answer. 

Control  within  a  CLIPS  program  can  be  adtieved 
by  using  facts  as  controls  but  CLIPS  provides  a 
more  direct  method  of  control  through  salience. 
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This  allows  assignment  of  priority  to  niles,  to 
ensure  that  the  highest  priority  rule  in  a  set  will  fire 
first  even  if  others  are  available  to  fire  also. 

CLIPS  provides  several  commands  to  help  in 
debugging.  One  command  allows  you  to  continu¬ 
ously  watch  facts  being  asserted  and  retracted. 
Whenever  a  fact  is  asserted  or  retracted,  it  will  be 
displayed  as  such.  Assertion  of  the  fact  (new_fact) 
would  cause  the  disifiay 

=>  f-1  (tvew_fact) 

If  this  fact  was  then  retracted,  the  display  would  be 
<=  f-2  (new_fact). 

It  is  also  possible  to  watch  rules  and  activations  on 
the  agenda  as  the  program  is  executing. 

3.2  Fortran  Library  for  EXpert  Systems,  FLEX 

Flex  is  a  library  of  Fortran  77  subroutines  for 
developing  Expert  System  modules  to  interface 
directly  with  Fortran  programs.  It  was  developed  at 
RAE^  and  has  already  found  application  in  the  field 
of  aircraft  structural  design'^. 

As  well  as  the  subroutines,  a  separate  readable 
knowledge  base  is  supported,  together  with  for¬ 
ward,  backward  and  hypothesis  /  constraint 
inferencing.  Basic  explanation  facilities  are  also 
provided.  The  FLEX  library  can  be  called  from  a 
higher-level  Fortran  program  to  implement  the 
inferencing  procedures  required  by  the  problem.  A 
knowledge  base  in  FLEX  consists  of  a  number  of 
separate  rule  bases  contained  within  the  knowledge 
base. 

3.2.1  Rule  Format 

Rules  are  represented  in  the  following  form; 
Rule-identifier 

IF  property-a  AND  propetty-b . 

THEN  property-x  AND  propcrty-t.... 
EXP=Explanation; 

Disjunctive  rules  (i.e.  rules  whose  antecedents  con¬ 
tain  facts  linked  by  ‘OR’  functions)  can  also  be 
used,  in  which  case  and  ‘AND’  operator  takes  pre¬ 
cedence  over  ‘OR’.  In  other  words. 


‘if  A  and  B  or  C  and  D’ 

means  if  A  and  B  are  both  true,  or  if  C  and  D  are 
both  true. 

The  negative  of  a  property  is  denoted  by  a  ‘not_’ 
(optionally  ‘-’)  directly  before  fire  name  (e.g. 
-mammal  means  not  a  mammal). 

3.2.2  Representation  of  Facts. 

The  facts  which  correspond  to  particular  properties 
are  stored  in  an  array  provided  by  the  user.  Each 
fact  can  be  in  one  of  three  states:  true,  false  or 
unktwwn.  There  is  no  fact  list  as  such,  rather,  when 
the  rule  bases  are  read  in  by  the  driving  Fortran 
program,  the  properties  and  their  associated  values 
are  stored  in  the  aforementioned  array.  This  is 
unlike  a  system  such  as  CLIPS,  where  facts  are 
only  stored  in  the  fact  list  if  they  have  been 
asserted.  In  FLEX,  all  the  properties  used  in  a  rule 
base,  as  both  antecedents  or  consequents,  will  be 
placed  in  the  array  when  the  rule  base  is  read  in. 

The  fact  value  associated  with  each  property  can 
then  be  set  explicitly.  The  setting  of  a  fact  value 
can  be  considered  to  be  the  same  as  asserting  a  fact 
in  CLIPS,  and  similarly,  setting  a  fact  value  to  false 
can  be  considered  the  same  as  retracting  a  fact. 

4.  The  Knowledge-Based  Autopilot 

To  illustrate  the  proposed  approach  to  the 
verification  and  validation  of  KBSs,  a  rule-based 
longitudinal  altitude-conunand  autopilot  example 
for  a  high  performance  fighter  aircraft  has  been 
designed.  The  example  presented  represents  a  sin¬ 
gle  axis  of  a  three-axis  Oongitudinal,  lateral- 
directional,  and  velocity)  controUer.  This  controller 
is  being  developed  and  will  be  qualified  as  a 
mission-critical  system  as  part  of  the  research  into 
validation  methodologies  for  operation-critical 
KBSs. 

A  simplified  representation  of  the  aircraft  and  con¬ 
trol  system  is  shown  in  figure  1.  The  objective  is  to 
develop  and  to  demonstrate  a  knowledge-based 
controUer  that  produces  command  inputs  to  the  air¬ 
craft  control  system  based  on  a  dynamic  worid 
model  obtained  from  instruments  on  the  aircraft  and 
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on  a  simple  set  of  rules.  While  this  task  may  not 
represent  a  suitable  end-application  of  a  KBS 
(because  it  is  easily  perfoimed  by  conventional 
algorithmic  control  laws),  it  provides  a  simple 
mission-critical  ai^cadon  that  is  both  easy  to 
understand  and  easy  to  validate. 

The  control  task  requires  the  autopilot  system 
(whether  based  on  conventional  algorithms  or  a 
knowledge-based  af^roach)  to  produce  commands 
that  cause  the  measured  aircraft  altitude  /t  to  be 
within  some  specified  tolerance  AA  of  the  com¬ 
manded  altitude  h  .  Additionally,  constraints  are 
placed  on  the  altitude  rate  and  the  normal  accelera¬ 
tion  a  .  The  constraint  on  a  is  the  same  as  a  con- 

n  n 

straint  on  altimde  acceleration,  but  represents  a 
more  easily  understood  and  easily  measured  physi¬ 
cal  quantity. 

The  initial  requirement  for  this  controller  was  that  it 
control  the  aircraft  in  a  consistent,  repeatable 
manner  at  least  as  well  as  a  pilot  during  both  the 
transition  mode  (going  from  one  altitude  to  another) 
and  the  altitude-hold  mode  (controlling  the  aircraft 
about  a  specified  altitude).  The  desire  was  to  have 
it  control  the  aircraft  as  well  as  a  conventional 
algorithmic  autopilot.  An  additional  goal  was  to 
allow  off-condition  engagement  so  that  the  con¬ 
troller  would  also  be  effective  even  without  benign 
initial  (engagement)  conditions. 

These  goals  and  requirements  are  similar  to  those 
initially  imposed  on  the  altitude-hold  capabilities  of 
the  flight  test  maneuver  autopilot  for  the  HiMAT 
vehicle^^.  The  constraints  and  tolerances  were  esta¬ 
blished  as  baseline  figures.  From  this  initial 
Reification,  a  nile-based  system  was  implemented 
that  combined  numeric  and  symbolic  methods.  This 
initial  system  was  tested  using  a  detailed  nonlinear 
simulation  model  of  the  aircraft  and  its  control  sys¬ 
tem;  the  controller  achieved  exceUeitt  results  for 
some  initial  conditions  but  performed  pooily  for 
many  others.  This  initial  result  was  typical  of  that 
exp'.rienced  when  evaluating  die  initial  implementa- 
tion  of  a  conventional  ctmtroller  on  a  nonlinear 
siir  uladoa  After  several  iterations  of  this  process,  a 
fairly  detailed  statement  of  performance  oprtiilities 
and  limitations  was  estaUidied.  This  information, 
in  essence,  represents  clarification  of  the  statement 


of  goals  and  requirements  and  serves  as  the  basis 
of  a  functional  specification  for  the  system.  An 
example  of  a  prototype  set  of  rules  for  the  longitu¬ 
dinal  altitude-hold  section  of  the  rulebase  is  given 
in  the  following  table. 

TABLE  Preliminary  Rules  for  Longitudinal 
Altitude-Hold  Autopilot 

Performance  boundary  rules 

•  If  the  altitude  acceleration  exceeds  the  positive 
acceleration  limit,  move  stick  forward. 

•  If  the  altitude  acceleration  exceeds  the  negative 
acceleration  limit,  move  stick  aft 

•  If  the  predicted  altitude  rate  exceeds  the  positive 
altitude  rate  limit,  trim  stick  forward. 

•  If  the  predicted  altitude  rate  exceeds  the  negative 
altitude  rate  limit,  trim  stick  aft. 

Normal  command  rules 

•  If  the  altitude  error  is  positive  and  the  predicted 
altitude  rate  is  negative,  trim  stick  aft. 

•  If  the  altitude  error  is  negative  and  the  predicted 
altitude  is  positive,  trim  stick  forward. 

•  If  the  predicted  altitude  error  is  positive  and  the 
altitude  error  is  smaU,  click  stick  forward. 

•  If  the  predicted  altitude  error  is  negative  and  the 
altitude  error  is  small,  click  stick  aft. 

•  If  the  predicted  altitude  error  is  positive  and  the 
altitude  error  is  large,  trim  stick  forward. 

•  If  the  predicted  altitude  error  is  negative  and  the 
altitude  error  is  large,  trim  stick  aft. 

Definitions: 

move  large  movement  of  stick 
trim  intermediate  movement  of  stick 
click  small  movement  of  stick 

4.1  Possible  Implementation  Using  FX.EX 

The  aim  of  this  project  is  to  re-implement  an  exist¬ 
ing  KBAP,  supplied  by  NASA  and  written  in 
CXIPS,  in  FLEX,  the  Fortran  Libraiy  ft)r  Expert 
System  Development.  The  reasoning  behind  this  is 
fiiat  FLEX  has  proven  to  be  much  faster  than 
CLIPS  and  other  currently  available  expert  systems 
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on  benchmaiking  problems.  It  is  hoped,  therefore 
that  a  FLEX  implemeniatioa  of  the  KBAP  can  be 
made  to  run  in  real  time. 

Hie  intention  is  to  provide  exactly  the  same  func¬ 
tionality  as  the  CLIPS  veisioa  Therefore  the 
knowledge  used  in  die  CLIPS  version  has  to  be 
extracted  and  then  rewritten  in  a  form  diat  could  be 
used  by  FLEX.  Thus,  the  FLEX  implementation 
would  not  require  any  knowledge  engineering  in 
the  fonn  of  consulting  a  human  expen  on  autopi¬ 
lots,  since  this  work  has  already  been  done  by 
NASA. 

The  usual  method  used  for  translating  rules  from 
one  expen  system  language  to  another  is  to  first 
rewrite  the  niles  in  English,  using  a  structured  for¬ 
mat  of  IF  THEN  constructs.  Once  this  knowledge 
has  been  extracted  and  rewritten  into  a  FLEX 
knowledge  base,  Fortran  driving  code  will  have  to 
be  written  to  utUits  it  FLEX  is  not  a  self-contained 
expen  system  like  CLIPS;  rather  it  is  a  set  of  For¬ 
tran  subroutines  that  utilise  the  decision  making 
capabilities  of  expen  systems  The  difference 
between  its  capability  and  that  of  CLIPS  will  neces¬ 
sitate  some  changes  to  the  division  of  labour 
between  the  algorithmic  and  knowledge  based  parts 
of  the  system.  In  particular,  FLEX  does  not  allow 
arithmetic  expressions  within  rules,  so  all  calcula¬ 
tions  will  have  to  be  done  by  the  algorithmic  pan 
of  the  autopilot  which  will  assen  facts  for  con¬ 
sideration  by  the  rule-base. 

A  preliminary  investigation  has  been  carried  out  on 
the  conversion  of  a  typical  set  of  autopilot  rules 
into  FLEX.  This  has  proved  to  give  very 
encouraging  results.  The  combination  of  the  re- 
structing  as  above,  and  the  greater  efficiency  of  the 
FLEX  infereiKing  procedure  gave  a  speed  improve¬ 
ment  well  in  excess  of  a  factor  of  ten  over  the 
CLIPS  version,  using  a  Sun  3  processor.  This 
should  provide  amide  scope  for  real-time  opera¬ 
tions,  even  if  the  fiiud  KBAP  rules  adopted  prove 
to  be  more  complex  than  this  preliminary  set 

Worit  on  ifflplemenling  Knowledge-Based  Systems 
in  conventional  languages  is  continuing  at  RAE, 
and  an  Ada-based  KBS  toolkit  is  likely  to  be  avail- 
aUe  within  the  timescales  of  this  projea^^.  It 


would  be  a  valuable  extension  of  the  CRISP  work 
to  investigate  a  re-implementation  using  Ada  as  a 
comparison. 

5.  Approaches  to  the  Validation  and 
Verification  of  the  KBAP 

The  V&V  methodology  used  at  Ames-Diyden  is 
the  same  methodology  diat  has  actually  been  used 
for  all  flight-critical  control  systems  in  non¬ 
commercial  aeronautical  flight  vehicles,  including 
the  F-18,  Space  Shuttle,  and  B-1  aircraft.  This 
methodology  uses  a  subset  of  the  V&V  techniques 
in  use  or  advocated  within  the  aeronautics  com¬ 
munity.  The  larger  issues  of  certification  and  the 
validation  of  highly  reliable,  fault-tolerant  systems 
have  been  of  lesser  concern  than  those  of  qualify¬ 
ing  and  conducting  flight  validation  of  flight-critical 
systems. 

The  basic  methodology  for  the  V&V  of  conven¬ 
tional  operation-critical  systems  is  directly  applica¬ 
ble  to  the  V&V  of  KBSs.  In  fact,  if  KBSs  are  to  be 
used  in  operation-critical  ap^ications,  the 
qualification  of  these  KBSs  will  have  to  be  per¬ 
formed  within  the  context  of  established  procedures 
and  will  have  to  address  the  requirements  placed 
upon  the  qualification  of  conventional  operation- 
critical  systems. 

The  basis  of  the  Ames-Diydoi  flight  qualification 
and  V&V  methodology  for  embedded  flight-critical 
systems  is  the  incremental  verification  of  systems 
components,  integration  testing,  configuration 
management,  and  flight  validation.  The  design 
specifications  are  transformed  into  hardware  and 
software  realizations.  This  transformation  is  not  a 
straightforward,  one-step  process.  The  transforma¬ 
tion  of  a  design  Reification  to  an  implemented 
prototype  system  requires  the  development  and  test¬ 
ing  of  numerous  software  iMocedures  and  hardware 
circuits,  each  of  which  is  a  prototype  of  stnne  ele¬ 
ment  in  die  larger  system. 

The  imiflemeiitaticHi  of  system  elements  or  com¬ 
ponents  is  supported  Iw  a  variety  of  analysis  tools 
and  testing  techniques'*^  .  The  analysis  tools  used 
include  figure  modes  and  effects  analysis,  indqiai- 
dent  review,  static  verification,  independent  calcula- 
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tions,  conjectures,  and  suspidons.  This  analysis  is 
conducted  on  abstract  models  of  the  system  or  of 
the  system  components.  Linear  systems  models, 
aggregate  system  models,  block  diagrams,  flow 
diagrams,  schematics,  source  programs, 
specificaticms,  and  simulations  are  some  of  the 
main  abstract  models  used.  This  analysis  of  abstract 
models  is  used  to  translate  requirement  and  design 
^dfications  into  a  physical  realization. 

Simulation  testing  provides  a  closed-loop  facility 
wherein  the  system  is  exposed  to  an  environment 
that  closely  resembles  the  electronic  and  data 
environment  in  which  the  system  must  actually 
operate.  Simulation  also  provides  a  facility  for  test¬ 
ing  that  the  hardware  and  software  of  the  syston 
are  integrated  and  operating  together.  Simulation  is 
where  the  pilot  (the  system  user)  is  first  exposed  to 
the  system  and  allowed  to  evaluate  it;  the  realism 
of  the  simulation  is  determined  by  the  operating 
requirements  for  the  flight  application  of  the  sys¬ 
tem. 

The  V&V  methodology  used  for  conventional, 
embedded  operation-critical  flight  systems  provides 
an  established  and  accepted  set  of  procedures  upon 
which  a  methodology  for  KBSs  can  be  based. 

While  this  position  may  be  controversial  in  the  AI 
community,  the  political  and  sociological  realities 
of  flight  research  and  testing  will  ultimately  dictate 
that  any  methodology  for  the  validation  of  KBSs  at 
least  address  the  currently  used  methodology  for 
conventional  systems. 

The  proposed  approach  to  the  V&V  of  KBSs  relies 
on  the  life  cycle  model  shown  in  figure  2.  The  life 
cycle  model  for  a  KBS  has  been  a  topic  of  consid¬ 
erable  concern  to  some  who  have  addressed  the 
validation  of  a  KBS,  and  several  models  have  been 
proposed'^’^^'^^.  These  models  stress  the  develop¬ 
ment  and  prototyping  process  in  a  KBS.  The 
motivation  for  developing  these  models  is 
apparently  to  address  the  lade  of  a  clear  or  well- 
defined  statement  of  system  goals  and  requirements 
and  to  highlight  the  prototyping  process  common  in 
the  develqxnent  of  KBSs.  While  the  proponents  of 
tiiese  models  would  piobaUy  contend  that  diere  is  a 
fundametttal  difference  betw^  the  life  cycle  of  a 
KBS  and  a  conventkmal  syoem,  owther  view  is 


that  this  iq^parem  difference  is  more  reflective  of 
the  maturity  of  KBSs  rather  than  of  anything  funda- 
metttal. 

Because  KBSs  are  just  emerging  in  operation- 
critical  plications,  there  is  little  certainty  of  erqra- 
bilities  atxl  limitations  of  these  systems.  The  proto¬ 
typing  that  is  a  common  feature  in  the  development 
of  a  KBS  often  represents  an  attempt  to  establish 
requirements  for  a  given  plicatioa  This  definition 
of  requirements,  capabilities,  and  limitations 
throu^  prototyping  is  rtot  utdike  that  used  in  con¬ 
ventional  systems  when  new  techniques  or  plica¬ 
tion  are  attempted.  The  difference  is  in  the  body  of 
knowledge  and  experience  behind  the  use  of  con¬ 
ventional  systems  as  opposed  to  that  of  KBSs.  Also 
reflected  in  this  prototyping  is  the  lack  of  maturity 
of  artifidal  inteUigence  (AI)  tedmiques  in  general 
tirat  provides  little  basis  for  die  selection  of  control 
and  knowledge  representation  metiiods. 

There  ate  several  issues  tiiat  ate  almost  certain  to 
create  problems  for  anyone  attempting  to  validate 
operation-critical  KBSs.  Perhp  the  most  serious 
of  these  is  an  unwillingness  to  treat  the  current  gen¬ 
eration  of  KBSs  out  of  the  context  of  the  pitxnises 
of  AI.  The  current  generation  of  KBSs  are  not,  in 
general,  capable  of  learning  or  evm  modestly  adap¬ 
tive.  These  systems  exhibit  few  nondeterministic 
properties.  These  KBSs  may  be  complex  but  they 
are  not  urqrredictable.  But  so  long  as  there  is  this 
persistence  in  dwelling  on  the  ultimate  potential  of 
AI  systems  instead  of  on  the  realities  of  the  system 
being  qualified,  it  is  unlikely  that  an  airworthiness 
and  flight  safety  review  (  AFSR  )  pand  would 
allow  flight  testing. 

A  further  difficulty  arises  from  the  ctmtration  the 
KBSs  do  not  always  produce  the  correct  answer.  If 
this  is  true  then  a  KBS  can  only  be  used  for  tasks 
in  which  tiieir  perfotmaiKe  can  be  monitored  and 
overridden  by  a  human.  Most  operation-critical  sys¬ 
tems  are  required  to  perform  without  human  inter¬ 
vention  or  with  only  high-level  supervision  or  con¬ 
trol.  However,  a  KBS  that  does  not  always  produce 
the  optimum  answer  is  accqriaUe  as  loi%  as  it 
never  produces  a  wrong  answer.  This  latter  point  is 
in  fact  one  of  the  main  V&V  issues:  operation- 
critical  systems  must  be  d»wn  to  produce  accept- 
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able  solutions  in  all  situations. 

There  are  two  key  aspects  of  the  proposed  approach 
tothe  V&VofKBSs: 

1.  develo{Hnent  of  a  KBS  to  perfonn  some  task 
that  is  well-known,  well-understood,  and  for  which 
conventional  V&V  techniques  are  adequate;  and 

2.  incrementally  and  simultaneously  expand  both 
the  KBS  and  the  V&V  techniques 

to  more  demanding  and  complex  tasks. 

The  procedures  used  for  verifying,  qualifying,  and 
validating  conventional  opetation-critical  flight  sys¬ 
tems  at  Ames-£>ryden  will  be  applied  and  modified 
as  required.  Because  we  ultimately  plan  to  carry 
these  experiments  to  flight  using  the  rapid¬ 
prototyping  facility^,  this  process  will  be  performed 
under  the  aegis  of  an  AFSR  panel  and  will  be 
under  periodic  review.  The  subject  of  this  research 
will  be  the  knowledge-based  autopilot  (KBAP) 
described  above,  that  is  being  developed  ultimately 
to  perfonn  aircraft  maneuvers  normally  performed 
by  highly  trained  pilots. 

The  research  plan  is  to  idoitify  maneuvers  of 
increasing  difficulty  and  to  build  gradually  more 
complex  and  adaptive  KBS  to  accomplish  those 
maneuvers.  This  wiU  include  prototyping,  evalua¬ 
tion,  and  a  series  of  initial  operating  capabilities 
that  will  evolve  into  a  sequence  of  documented 
requirements  for  testing  against  each  version  of  the 
system.  This  approach  fits  well  within  the  model  of 
and  practice  used  with  conventional  digital  systems. 

6.  Conclusions 

This  ptq)er  has  described  a  proposed  collaborative 
programme  of  research  intended  to  approach  the 
problem  of  the  validation  and  verification  of 
mission-critical  krowledge-based  systems  in  an 
incremental  manner,  using  established  procedures. 
The  view  presented  in  this  piqrer  is  consistent  with 
that  propo^  in  Gault^  and  others: 

A  validation  methodology  for  ultrahigh  relia¬ 
bility,  fault-toIerBU  systems  must  be  based  on 
a  judicious  combinadon  (^logical proofs. 
MofyOcal  modeling,  and  experimental  testing. 


This  methodology  must  be  suf^rted  by  reliable 
validated  development  and  test  tools  that  lower  the 
cost  and  reduce  die  schedule,  if  the  goal  of  valida¬ 
tion  is  to  be  adiieved  for  either  highly  reliable, 
fault-tolerant  systems  or  highly  ctnnplex  systems 
such  as  are  envisioned  for  KBSs. 

The  work  will  focus  on  the  real-time  implementa¬ 
tion  of  a  knowledge-based  autopilot  designed  by 
NASA  using  a  real-time  KBS  tool,  FLEX,  written 
at  RAE.  Preliminaiy  results  on  a  representative 
rule-set  indicate  that  FLEX  will  have  more  dian 
sufficient  speed  for  this  plication.  The  possibility 
also  exists  of  an  Ada  implementation  at  a  later 
stage. 

The  specific  structures  used  within  the  real-time 
version  may  well  influence  some  aspects  of  the 
approach  taken  towards  validation,  in  particular  the 
position  of  the  boundary  between  the  algorithmic 
and  rule-based  sections  of  the  autopilot  It  is  hoped 
that,  if  the  validation  arxl  verification  work  is  suc¬ 
cessful,  then  flight  tests,  using  tte  NASA  Ames- 
Dryden  Rapid  Prototyping  Facility,  could  be  under¬ 
taken. 
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Discussion 

1.  W.G.  Semple,  United  Kingdom 

I  understand  that  you  approach  the  clearance  problem  by 
constraining  the  rule  base  to  be  such  that  all  possible  states 
can  be  identified  and  assessed.  Does  that  reduce  the 
verification  problem  to  that  of  conventional  code,  this 
ducking  the  stated  c^jective? 

Author; 

If  I  understood  the  tpiestion,  the  answer  is  no,  that's  just  step 

1 .  The  project  will  proceed  to  bigger  rule  bases.  Yes,  wc  hope 
in  future  versions  to  have  a  more  complex  rule  set  with 
different  autopttotmodes  and  more  likelihood  of  interaction 
between  rules. 

2.  Carl  Lizza,  United  States 

If  you  have  a  small,  well-defined,  simple  ruleset  to  facilitate 
verification  then  why  use  a  rule-based  paradigm  at  all?  Why 
not  code  the  rules  as  procedural  logic? 

Author: 

Coding  the  system  in  procedural  logic  would  negate  our 


effort  to  explore  the  verification  and  validation  issued  for  a 
knowledge  based  system. 

3.  MA.T.Timmers,  Netherlands 

Your  objective  was  to  develop  a  knowledge  based  autopilot 
which  could  be  certified  by  the  applicable  agencies.  How  did 
this  objective  reflect  in  the  actual  design? 

Author: 

In  the  first  version  of  the  knowledge  base  we  have  been 
constrained  to  a  design  with  relatively  few  rules  which  can  be 
shown  not  to  be  in  conflict  with  each  other. 

4.  R.  Guiot,  France 

Why  not  use  fuzzy  logic  control? 

Author 

I  would  be  very  interested  to  look  into  the  possibility  of  using 
fuzzy  logic.  I  should  reiterate  that  the  main  purpose  of  the 
work  is  not  to  produce  the  best  possible  autopilot,  but  to 
investigate  verification  and  validation  issues  relating  to 
mission  control  KBS  .systems.  It  will  be  interesting  to  see 
whether  fuzzy  logic  has  advantages  for  verification  and 
validation. 
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ADAPTIVE  TACTICAL  NAVIGATION  PROGRAM 


Sandra  L.  Beming 
Wright  Laboratory 
WL/AAAN-2 
WPAFB,  OH  45433 
USA 

ABSTRACT 


The  Avionics  Directoraje  of  the  Wright  Lab¬ 
oratory  at  Wright-Patterson  ^  Force  Use  spon¬ 
sored  development  of  tha  Ad^ptivtf  Tactical 
Navigation  (ATN)  system  mm  1986-1990.  The 
ATN  system,  develrq)^  by  lASC  under  contract 
to  the  United  States  Air  Foree,  is  a  labmatory  pro¬ 
totype  which  incorporates  Imowledgif  based  soft¬ 
ware  designed  to  p^om  naviganon  system 
management  and  decisiort/aiding  for  the  next  gen¬ 
eration  of  combat  aircraft.  The  purpose  of  the 
ATN  system  is  to  manage  a  future  multisensor 
navigation  suite,  dynamically  selecting  the  most 
rqrpropriate  navigation  equqxnent  to  use  in  accor- 
dwce  with  mission  goals,  mission  phase,  threat 
environment,  equipment  health,  equqnnent  avail¬ 
ability,  and  battle  damage.  The  ATN  system  en¬ 
compasses  functions  as  diverse  as  sensor  data 
interpretauon,  diagnosis,  and  navigation  resource 
plannin| 


This  paper  describes  the  motivation  for  pur¬ 
suing  this  avenue  of  research,  the  ATN  design  and 
devdopment  processes,  results  obtained,  and  les¬ 
sons  learned.  - 


BACKGROUND 


To  succeed  in  the  complex  mission  environ¬ 
ment  of  the  mid-1990s,  combat  aircraft  will 
require  advanced  ciqiabilities.  Among  diese  capa¬ 
bilities  ate:  robustness  to  electronic  countermea¬ 
sures,  automatic  tenain  followingAerrain  avoid¬ 
ance,  efEective  in-weather  operatirms,  and  the 
potoitial  for  covert  operatkmsdirough  strict  emis¬ 
sions  management.  Also,  air  defense  system  de¬ 
ployments  to  defend  hi^-valoe  fixed  targets  will 
retpire  sorvivatrility  tactics  sudi  as  standofC/blind 
or  maneuvering  weiqxm  deliveries.  Realizing  aU 
of  diese  advan^  mission  ogiabilities  requires 
highly  accurate,  robust,  md  reliaMe  navigation 
system  petfotmance. 

To  meet  die  ftiU  range  of  mission  teqi^- 
ments,  com|denientary  Mgh  accuracy  tuviga- 
tkm  sensofs  are  beam  integrated  oi^ard  ad¬ 
vanced  combat  aircra^  Among  these  advanced 
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systems  are  the  Global  Positioning  System  (GPS), 
Joint  Tactical  Information  Distribution  System 
(JTIUS),  and  terrain  reference  navigation  (e.g., 
Sandia  Inertial  Terrain  Aided  Navigation).  Ad¬ 
vanced  techniques  are  required  to  take  full  ^van¬ 
tage  of  all  navigation  resources  while  minimizing 
demands  on  the  pilot/aircrew  for  system  interpre¬ 
tation  and  management. 


INTRODUCTION 

The  objectives  of  the  Ad^tive  Tactical  Navi¬ 
gation  program  were  to  determine  the  utility  of  an 
intelligent  system  manager  controlling  the  navi¬ 
gation  system  of  amid-1990’s  combat  aircraft  and 
the  suitabflity  of  current  technology  for  imple¬ 
menting  such  a  design.  The  techiucal  effon  en¬ 
tailed  £e  design,  development,  and  demonstra¬ 
tion  of  a  system  which  performs  system  manage¬ 
ment  and  decision  aiding  functions  for  the  proj¬ 
ected  multisensor  navigation  suite  of  mid-1990’s 
attack  aircraft.  The  god  for  the  ATN  system  was 
to  provide  a  high  quality  navigation  solution 
whde  mirumizing  interpretation  and  interaction 
(“switchology”)  demands  on  the  pilot/aircrew. 

The  ATN  system  was  developed  and  eva¬ 
luated  in  a  laboratory  environment  followed  by 
rehosting  and  evaluation  in  an  F-16C  cockpit  sim¬ 
ulation  dome.  Evaluation  results  indicate  opera¬ 
tional  deployment  of  a  system  that  utilizes  the 
technology  develtqied  urider  the  ATN  program 
could  resdt  in  enhanced  use  of  navigation  re¬ 
sources,  reduced  pilot  workload,  improved  situa¬ 
tional  awareness,  and  intelligent  navigation 
system  failure  detection  and  isolation.  Collective¬ 
ly,  these  benefits  result  in  an  overall  improvement 
in  mission  effectiveness. 


ATN  SYSTEM  OVERVIEW 

The  ATN  system  consists  of  two  major  com¬ 
ponents;  the  Bask  Navigation  System  wluch  inte¬ 
grates  die  sensor  outputs  into  navigation  solutions 
and  the  Expert  Navigation  System,  whkh  pro¬ 
vides  syston  management  a^  decision-aiding 
functionality. 
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A  set  of  sensors  representative  of  the  tech¬ 
nology  antic^ated  to  be  operational  by  the  mid- 
1990s  was  selected  as  the  ATN  sensor  suite;  viz.,  a 
Strapdown  Initial  Navigation  System  (INS), 
GPS,  Sandia  Inertial  Terrain  Aidc^  Navigation 
(SITAN),  Syndwtic  Aperture  Radar  (SAR),  Dop¬ 
pler  Radv,  and  an  Electro-Optical  (B3)  System. 
The  ATN  system  was  designed  to  c^itaUze  on  the 
strengths  of  this  sensor  suite,  minimize  the  work¬ 
load  demands  of  managing  sudi  a  complex  sensor 
suite,  and  compensate  for  all  inherent  constraints 
imposed  when  using  a  particular  sensor. 


ATN  SYSTEM  DESIGN 

Significant  issues  addressed  in  the  ATN 
design  effort  included:  Domain  of  Functionality, 
Architectures,  and  Knowledge  Acquisition.  Key 
results  of  ATN  System  design  efforts  are  summa¬ 
rized  below. 

ADi  Domain  of  .FuactiQiMlity  —  System 
management  and  advisory  function  that  the  ATN 
system  could  and  should  perform  were  deter¬ 
mined.  To  select  these  functions,  assessments 
were  performed  of  both  the  feasibility  of  imple¬ 
menting  functions  and  the  projected  improvement 
in  mission  effectiveness  and  reduction  in  crew 
workload.  Three  broad  classes  of  functions  were 
selected  for  the  ATN  effort;  viz.,  Sonsor  Integra¬ 
tion  and  Navigation  Computations,  System  Man¬ 
agement,  and  Decision  Aiding. 

The  first  class  of  fiinctirms  (Sensor  Imegra- 
don  and  Navigation  Computations)  is  performed 
by  a  portitm  of  the  ATN  system  termed  the  Basic 
Navigation  System  (BNS).  The  BNS  integrates 
data  from  a  variety  of  available  navigation  sensors 
to  form  a  usable  vehicle  navigation  state  output. 
This  is  accomjdiahed  by  using  Kalman  filters  to 
estimate  time-correlated  navigation  state  parame¬ 
ters  and  sensor  model  parameters  by  optimally 
combining  sensor  measurement  data.  A  related, 
secondary  function  of  the  BNS  is  to  provide  sen- 
soT-relat^  navigation  dau  to  the  intelligent  por¬ 
tions  of  the  ATN  system  to  aid  in  the  recognition 
of  special  or  problm  situations  and  to  support  the 
reconfiguration  or  adjutant  of  the  BNS  to  best 
meet  user  requirements. 

The  secoitd  and  third  classes  of  functions 
(Systm  Management  and  Decision  Aiding)  are 
pcsftnmed  by  tite  remaining  portions  of  the  ATN 
system  whidi  ctdlectiveiy  ate  lefened  to  as  the 
Ejqmt  Naviption  System  (ENS).  Ihbte  1  lists  the 
priinaiy  fimokms  perfimned  foe  ENS.  Func¬ 


tions  1  through  10  are  system  management  func¬ 
tions  aimed  at  monitoring  and  diagnosing 
sensor/basic  navigation  behavior  and  supporting 
equqanent  recottfiguration  (moding  transitions). 
Functions  11  through  16  in  Table  1  support  user 
decision  aiding  in  selecting  navigation  sensors/ 
cottfigurations  a]q>ropriate  to  the  current  and  pre¬ 
dicted  mission  requirements  and  resolving 
user-observed  navigation  anomalies. 


Table  1  Expert  Navigator  Functional 
Requirements  Cross  Reference 
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ATN  Architecture  —  The  BNS  architecture 
(Figure  1)  consists  of  a  baro-inertial  mechaniza¬ 
tion  and  four  federated  Kalman  filters.  A  feder¬ 
ated  Kalman  filter  iqiproach  was  selected  for  this 
application  because  of  its  superior  ability  to 
recover  an  unconuptcd  navigation  solution  oiKe  a 
failure  is  identified.  Switching  navigation  outputs 
from  one  filter  to  aiwther,  as  is  done  in  the  BNS, 
has  disadvantages  for  airc^  systems  that  depend 
on  ctmtinuous  navigation  data.  Fnmi  this  Ap¬ 
point,  a  centralized  Kalman  filt»  tq^roach  would 
have  an  advantage.  However,  the  federated  ap- 
proach  offers  the  ability  to  recover  quickly  firm 
soft  failures  and  achieves  better  data  protection 
wifo  little  sacrifice  in  performance  (Ref  1). 


NAV  Sy«t«m 
Output* 
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Figure  1  Basic  Navigation 
Table  2  Navigation  System  Combinations 


SYMBOL 

COMBINAnON 

SO 

INS*andGPS4 

SI 

GPS4 

S2 

INSaodGPS3 

S3 

INS  and  TAN 

S4 

INS,  DPR,  SAR,  and  EG 

S5 

GPS3,  DPR,  and  BARO 

S6 

GPS3  and  BARO 

S7 

INS  and  DPR 

S8 

INS,  SAR,  and  EO 

S9 

INS 

*INS  implies  INS  and  BARO  in  all 
cases  in  lUs  table 


To  establish  workable  BNS  architectures,  it 
was  necessary  to  identify  sensible  combinations 
of  sensors.  Ten  alternative  navigation  system  con¬ 
figurations  of  subsets  of  the  ATN  sensor  suite 
were  identified.  Systems  were  ranked  (Table  2) 
according  to  order  of  relative  accuracy.  The  ENS 
chooses  the  most  desirable  system  alternative 
based  on  expected  accuracy,  confidence,  and  mis¬ 
sion  segment  requirements. 

The  ENS  is  a  distributed  expert  system  that 
embodies  a  broad  range  of  functionality.  Parti¬ 
tioning  of  functions  among  the  experts  was  de¬ 
signed  to  localize  specie  sub-domains  of 
navigation  expertise  such  as  missitm  manage¬ 
ment,  eqpiipment  diagnosis,  and  sensor  cross- 
chectog.  Global-  and  module-level  architectures 
were  designed  for  die  ENS  to  realize  the  desired 
“intelligem”  fimctioiulity.  The  functiorul  organi¬ 
zation  of  the  ENS  is  depicted  in  Figure  2.  The 
fhnetiotudity  of  each  eaqieit  systems  is  described 
below: 


DECISIO 
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EOUIPMENT 
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Figure  2  Expert  Navigator  Functional 
Organization 

•  Navigation  Source  Manager  —  This  expert  is 
shown  for  GPS/INS,  SITAN,  and  Doppler-In¬ 
ertial.  It  uses  Kalman  Filter  outputs  and  design 
engineering  models  to  monitor  equipment  per¬ 
formance  and  to  detett  and  isolate  sensor  feil- 
ures  or  degradations. 

•  System  Status — This  expert  diagnoses  system 
“health”  based  on  reliability  data,  mission  en¬ 
vironment,  and  lower-level  diagnoses. 

•  Moding  Expert  —  This  expert  determines 
viable  component  combinations  based  upon 
current  equipment  status  and  determines  ap¬ 
propriate  handoif  strategies  for  mode  changes. 

•  Event  Diagnosis  —  This  expert  evaluates 
planned  navigation  events  (e.g. ,  a  waypoint  en¬ 
counter  and  designation)  and  diagnoses  anom¬ 
alous  or  out-of-spec  events  to  support  pilot 
moding  decisions. 

•  Mission  Manager  —  This  expert  stores  mis¬ 
sion  plan  and  environment  (threats,  ECM)  data 
and  determines  which  available  equipment 
configurations  are  appropriate  to  the  current 
and  forecasted  mission  situation. 

•  Pilot-Vehicle  Interface  (PVI)  Manager — This 
expert  manages  communication  between  the 
ATN  system  and  the  pilot. 

Knowledge  Acquisition— Knowledge  Engi¬ 
neering  for  the  ATN  program  included  both 
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Knowledge  Acquisition  and  Knowledge  Base  Im¬ 
plementation.  l^owledge  Acquisition  was  per- 
fonned  during  the  design  phase  of  the  program. 
Several  different  forms  of  knowledge  were  ac¬ 
quired  including:  existing  information  from  engi¬ 
neering  reports,  results  of  numerical  simulation 
(e.g.,  of  GPS  performance  degradation  in  jam¬ 
ming  scenarios),  and  human  knowledge  related  to 
navigation. 

Human  knowledge  covered  a  broad  range  of 
expertise  in  navigation  system  design,  mainte¬ 
nance,  and  operations.  Sources  of  human  knowl¬ 
edge  indud^:  operational  aircrews,  test  pilots 
and  engineers,  avionics  maintenance  technicians, 
navigation  system  and  design  engineers,  and 
avionics  system  engineers.  Obtaining  knowledge 
from  human  sources  posed  several  challenges  not 
usually  encountered  in  “classical"  knowledge  ac¬ 
quisition.  For  example,  in  1987,  when  the  ATN 
Knowledge  Acquisition  was  performed,  fielded 
systems  had  simple  navigation  suites  (e.g.,  INS 
with  visual  or  ground-ma^  radar  updating)  in  com¬ 
parison  with  the  suite  oivisioned  for  mid-1990s 
combat  aircraft.  Thus,  no  operational  or  test  air¬ 
crews  had  experience  with  the  multisensor  naviga¬ 
tion  suite  selected  for  ATN.  In  addition,  the 
interview  setting  did  not  replicate  the  actual 
onboard  environment  in  which  decisions  are 
made.  These  considerations  strongly  influenced 
the  interview  aj^roach,  the  information  that  was 
obtained,  and  the  selection  of  knowledge  engi¬ 
neering  techniques. 

Approximately  fifty  individuals,  each  an  ex¬ 
pert  in  a  subset  of  tte  domain,  were  interviewed  as 
part  of  the  ATN  Knowledge  Acquisition  effort. 
Specific  sources  of  human  knowledge  and  the 
types  of  information  obtained  from  those  sources 
were: 

•  Tactical  and  Strategic  Aircrews  —  Discus¬ 
sions  were  held  wi&  a  range  of  tactical  and 
strategic  aircrews,  representing  varying  expe¬ 
rience  levels  and  aircraft  avionics  vintage.  In¬ 
formation  obtained  provided  operator  perspec  - 
tive  of  mission  priorities,  current  navigation 
system  management  methodologies,  sensor 
cross-checking,  display  content^ormat  (both 
actual  and  dnired),  workload  profiles  as  a 
function  of  tnissicm  frfiase  and  sensor  utiliza¬ 
tion  in  a  single  seat  combat  aircraft,  and  work¬ 
load  q;)lit  b^ween  a  two-man  tactical  aircrew. 
Information  was  also  obtained  regarding  the 
operational  use  of  radio  navigatimi  aids  (LO- 
RAN),  an  EO  targeting^pdate  system  (PAVE 
TACK),  a  recei^  modernized  navigation 
suite  ftiat  utilizes  a  Kalman  Filter  to  incorpo¬ 
rate  Dtqrfder,  true  air  q>eed,  and/or  discrete 


ground  map  radar  updates,  and  GPS  (on  a 
B-52), 

•  Flight  Test  Groups — Engineers  and  flight  test 
pilots  associate  with  GPS,  LANTIRN, 
SITAN,  and  a  digital  moving  map  evaluation 
provided  information  related  to  engineering 
development  and  limited  operation^  experi¬ 
ence  with  these  advanced  systems. 

•  Maintenance  Personnel  —  TASC  reliability 
engineers  and  Air  Force  maintenance  techni¬ 
cians  provided  insights  into  classes  of  ob¬ 
served  behavior  of  equipment  in  die  field  and 
experience-based  diagnosis  techniques. 

•  Design  and  System  Engineers  —  TASC,  Gen¬ 
eral  Dynamics,  and  Air  Force  Navigation  ana¬ 
lysts  and  designers  actively  designed  model- 
based  components  of  ATN  and  served  as  con¬ 
sultants  on  such  issues  as  GPS  receiver  per¬ 
formance,  operational  limitations  of  equip¬ 
ment,  current  design  practice  and  related  limi¬ 
tations,  and  reliability  engineering. 

An  organized  pre-brief  and  mission-centered 
questionnaire  supported  efficient  aircrew  inter¬ 
views.  This  questionnaire  was  provided  in  ad¬ 
vance  to  the  participating  Air  Force  operational 
organizations  as  a  preliminary  indication  of  our 
purpose  and  for  classification  guidance.  The  crew 
interviews  and  discussions  were  centered  on  a 
sample  tactical  interdiction  mission.  The  phases 
and  profiles  of  this  mission  are  shown  in  Figure  3. 
Also,  an  overview  of  the  navigation  suite  assumed 
for  the  mid-199()s  under  the  ATN  program  was 
presented  in  the  pre-brief. 


LANOMO 


Figure  3  Tactical  Mission  Profile 


The  ATN  System  was  developed  using  a  tra¬ 
ditional  waterfall  iqiproach  to  software  develop¬ 
ment  in  which  system  requirements  and  design 
were  established  before  system  development/ 
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coding  began.  This  phase  of  the  ATN  effort  in¬ 
cluded  development  of  the  BNS  and  ENS 
architectures  and  the  knowledge  based  compo¬ 
nents  defined  during  ATN  system  design  while 
meeting  the  requirement  for  an  AIT^  system 
which  could  demonstrate  real-time  performance 
and  be  suitable  for  subject-  interactive  testing  and 
evaluation.  Development  and  integration  of  the 
ATN  System  was  accomplished  in  stages: 

Development  of  the  Environment  Simulation. 

E)evelopment  of  the  BNS  and  integration  with 
the  envirorunent  simulation. 

Development  of  required  displays. 

Development  ofknowledge  basedcomponents. 

Development  and  component  testing  of  the 
Expert  Systems. 

Integration  and  stand  alone  testing  of  the  Expert 
Systems. 

Integration  of  the  BNS  and  the  ENS  and  func¬ 
tion^  testing  in  the  laboratory. 

Rehosting  and  system  evaluation  in  a  Cockpit 
environment. 

An  overview  of  each  development  stage  is  pro¬ 
vided  below. 

Environment  Simulation  Development  —  A 
complete  and  suitable  Environment  and  Sensor 
Simulation  (E/SS)  was  a  necessary  precursor  to 
development  of  the  BNS.  Existing  E^S  software 
(Integrated  Navigation  System  Simulation  or 
INSS)  was  restructured  and  augmented  to  meet 
this  need  (Ref  3).  A  strapdown  inertial  navigation 
system  model  was  developed  and  integral^  into 
the  INSS  software.  In  addition,  SAR  and  EO  sen¬ 
sor  models  were  integrated  into  the  existing  INSS 
structure  and  common  blocks  for  communication 
among  the  models  were  added. 

BNS  Development  —  Upon  completion  of 
the  E/SS  software,  the  BNS  was  develo{^  and  in¬ 
tegrated  with  the  E/SS.  The  BNS  (Figure  1)  con¬ 
sists  of  a  set  of  navigation  filters  managed  by  an 
executive,  aperformance  monitor  to  track  results, 
and  all  necessary  interfaces.  Except  for  the  per¬ 
formance  monitor  portion,  the  BNS  operates 
strictly  ftom  sensor  outputs  provided  by  the  E/SS. 
None  of  the  “truth  data”  available  from  the  envi¬ 
ronment  simulation  is  available  to  the  BNS  except 
for  performance  assessments. 

Displays  Development  —  The  head-up, 
head-down  display  complement  for  the  engineer¬ 


ing  system  is  shown  in  Figure  4.  The  displays 
were  implemented  on  two  Zenith  Z-248  PCs;  both 
display  computers  were  driven  by  data  from  the 
BNS  and  ENS  via  host  processor  (9600 B  aud)  ter¬ 
minal  ports.  User  interaction  was  implemented 
via  a  mouse  and  keyboard. 

The  head-up  display  provides  a  moving  hori¬ 
zon  (slaved  to  the  trajectory  data  from  the  E/SS) 
and  a  HUD  layout  based  on  that  of  the  Block  25 
F-16C.  The  HUD  display  includes  two  windows 
for  ATN  displays;  a  msstei  caution  that  displays 
yellow  on  warning  and  red  on  caution  and  an  ATN 
icon  window  for  posting  graphic  symbols  for  ATN 
advisories. 

The  head-down  display  consists  of  a  data 
entry  display,  two  multifunction  displays  and  a 
color  moving  map.  The  right  multifunction  dis¬ 
play  (MFD)  provides  a  simulated  radar  display 
widi  cursors  tha*  align  on  fixpoints  as  updates  are 
selected.  The  most  recent  aimpoint  offset  is  dis¬ 
played  in  the  data  entry  display  above  this  MFD. 
The  left  MFD  provides  a  help  facility  for  the 
grtqrhics  icons  displayed  on  the  HUD,  including 
the  meaning  of  the  icon  and  the  acceptable  re¬ 
sponses. 

The  512  X  512  pixel  moving  map  is  implem¬ 
ented  in  a  track-up,  decentered  orientation.  Each 
pixel  scales  to  100  meters  of  actual  distance;  the 
map  therefore  presents  51  km  of  flight  track,  or 
approximately  3  minutes  of  flight  time  (this  scale 
approximates  a  standard  1 :250,000  sectional  map 
scale).  The  data  for  the  map  was  obtained  by  digi¬ 
tizing  a  sectional  map  of  the  region  in  1 3  track-up 
segments.  The  mission  route  was  overlaid  on  the 
original  paper  map  before  scanning. 

Knowledge  Base  Implementation — Knowl¬ 
edge  Base  Implementation  for  the  ATN  effort  re¬ 
quired  both  selection  of  appropriate  knowledge 
representation  schemes  and  development  of  all 
knowledge  based  components. 

The  knowledge  representation  schemes  were 
selected  for  each  expert  system  based  upon  the 
type  of  reasoning  to  be  performed  within  that  ex¬ 
pert.  Representations  selected  for  ATN  include: 

Rules 

Procedures 

Relational  Data  Structures  (e.g.,  frames) 

Symbolic  Data 

Heuristically  assigned  probabilities  or 
weightings. 

Because  of  the  dichotomy  between  the  com¬ 
plexity  of  the  ATN  sensor  suite  and  the  simplicity 
of  fielded  systems  at  the  time  of  ATN  knowledge 
acquisition,  die  ATN  system  designers  used  non- 
tra^tional  techniques  to  develop  the  knowledge 
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Figure  4  ATN  Laboratory  System  Display 


required  for  the  ATN  knowledge  based  compo¬ 
nents.  Techniques  included  analogies  to  currently 
operational  systems  (e.g.,  GPS  versus  LORAN; 
LANTIRN  versus  PAVE  TACK),  and  cxtnqwla- 
tion  to  the  expected  ATN  system  complexity  and 
mission  environment.  Ttnis,  a  considerable 
amount  of  the  knowledge  for  the  ENS  expert  sys¬ 
tems  was  engineered  by  combining  results  of  op¬ 
erational  crew  discussions  with  designer  know¬ 


ledge  of  projected  system  characteristics  and 
future  mission  requirements. 

Details  regarding  the  knowledge  based  com¬ 
ponents  for  each  expert  system  are  summarized 
below: 
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Navigation  Source  Manager — The  Naviga¬ 
tion  Source  Manager  embo^es  two  forms  of 
knowledge: 

•  Knowledge  Source  Procedures  —  These  pro¬ 
cedures  provide  a  means  of  consistency  check¬ 
ing  among  GPS,  SITAN,  and  Doppler  sensors. 
This  was  based  upon  cross-che^  procedures 
described  during  discussions  with  Ohio  Air 
National  Guard  A-7D  pilots. 

•  Resource  Allocation  Logic — The  resource  al¬ 
location  logic  for  this  expert  system  was  devel¬ 
oped  by  design  engineering  methods  to  lead 
the  search  through  possible  multiple  failure 
combinations  (i.e.,  choices  of  alternative  par¬ 
ity  functions). 


Quick  Diagnosis  (environmental 
quality  effects) 

BIT  Screening. 

Moding  Expert  —  The  Moding  Expert  uti¬ 
lizes  symbolic  descriptions  of  sensors  and  modes 
and  categorical  symbolic  data  that  specifies  the 
mission-related  attributes  of  these  modes.  This 
symbolic  data  is  manipulated  by  procedures  to 
determine  viable  navigation  modes  based  on  cur- 
rendy  available  equipment.  The  symbolic  repre¬ 
sentations  of  the  modes  were  derived  from  the 
BNS  design.  Sensor  symbolic  descriptions  and 
mode  attributes  were  compiled  by  navigation  sys¬ 
tem  design  engineers.  Examples  of  the  mode  re¬ 
presentation  and  related  property  list  format  are 
provided  in  Table  4  and  Figure  5,  respectively. 


•  System  Status  Module  —  This  is  a  rule-based 
system  in  which  rules  are  organized  in 
“chunks”  that  correspond  to  specMc  subsys¬ 
tems  (e.g.,  INS,  GPS  receiver,  CADC,  Radar). 
Generic  forms  for  the  System  Status  rules  were 
developed  as  a  result  of  discussions  with 
FB-111  maintenance  technicians  at  Pease 
AFB,  NH.  These  generic  forms  fall  into  three 
categories  (Table  3): 


Ihble  3  System  Status  Rules 


•  A-Priori  Evaluation 

Rules  for  RcUaMUty  Factor  from  Maintenance  laformatiori 


FAILURE 

PRIDGNOSIS 

CND  FAILURES 

FREQUENT 

OCCASIONAL 

RARE 

Likely 

0.80 

0.85 

0.95 

Nominal 

0.85 

0-95 

l.OO 

Unltkeiy 

0.95 

too 

1  00 

•  Quick  Diagnosis 

Rules  for  Eovirooment  Quality  From  ECM  and  Weather  Indices 


1  ECM  1 

WEATHER 

HIGH 

MEDIUM 

LOW 

Advene 

Adverse 

Adverse 

Moderate 

Fair 

Adverse 

Moderate 

Favorable 

Rules  for  Eovlroiiffleiit  Quality  From  ECM  and  Weather  Indices 


SENSOR 

STATUS 

LOO 

1  ENVIRONMENT  QUALITY  \ 

ADVERSE 

MODERATE 

FAVORABLE 

Failed 

0  00 

000 

000 

Suspect 

0.60 

0.70 

0  80 

Normal 

085 

0.95 

i  00 

•  BIT  FaOurt  Evahiatieii 

Rules  for  Vallditr  of  Br  Failure  Pattens 

•IF  (Brr.FAILUFB  PATTEIW  -  ALWAYS  HAPPENS  PATTERNii) 
THEN  validity  -  0  5 

ELSE  IF  (Brr  FAILURE  PATTERN  •  KNOWN  FAILURE  PATTERNg) 
THEN  validity  -  I  0 
ELSE  VALIDITY  -  0  9” 


A  Priori  Evaluation  (modified  mission 
reliability. 


Table  4  Mode  Representations 


STANDARD  MODE  HIERARCHY  BASELINE  NON  STANDARD 

(STATIC)  CANDIDATES 


So 

INU  4  GPS4 

Ni 

INU  *  GPS3 

Si 

GPS4 

N2t 

♦  RADAR  ALTIMETER 

OR 

S: 

S) 

INU  ♦  GPS3 

INU  ♦  STN 

Nil 

♦  SAR/LANTIRN 

54 

Ss 

INU  ♦  DPR  ♦  S/L 

GPS3  ♦  DPR  ♦  BAR 

N» 

INU  +  STN 

s* 

CPS3  *  BAR 

Nil 

♦  OPS2^^ 

S? 

INU  ♦  DPR 

N» 

♦  DOPPLER  ♦  SaR/LASTIRN 
OR 

S| 

So 

INU  ♦  S/L 

INU 

♦  DOPPLER 

LIST  ENTRY  REPRESENTATION 

((<MOOE  CODE>.  <POINTER  TO  PLIST>.  <  POINTER  TO  DF.SCR1PT10NS>» 
EXAMPLE 

f(SO.  SO.PLIST.  SO. DESCRIPTION)  ) 


Mission  Manager  —  Three  knowledge- 
based  elements  were  developed  for  the  Mission 
Manager;  these  are; 

Weightings  for  a  mission  effectiveness  pay¬ 
off  fonction. 

A  decision  model  for  pre-attack  check  of  the 
navigation/bombing  system. 

Threat  models. 

Weightings  for  the  mission  effectiveness 
function  were  based  on  designer  judgment  derived 
from  discussions  with  F-16C,  F-4E,  and  FB-111 
aircrews.  A  set  of  tentative  premises  was  gener¬ 
ated  for  the  relative  importance  of  the  navigation 
mode  attributes  (see  Table  5)  as  a  function  of  mis¬ 
sion  phase;  these  are  listed  in  Table  6. 


OK  / 


QP«4 


/  I  \  WORKLOAD:  LOW 

MB  e  WO  •  1  mw.  • 


C  MM  •  IMM  ■ 


Figure  5  Example  Property  List 


y 
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Table  5  ATN  Navigation  Mode 
Attributes 


MODE 

DESCRIPTION 

ACCURACY 

ECM 

SUSCEPTIBILITY 

- 1 

EMISSIONS 

PILOT 

WORfCLOAD 

So 

INU  ♦GPS  4 

H 

M  (L  BAND) 

L 

L 

S| 

GPS  4 

H 

M(L  BAND) 

L 

L 

Si 

INU  ♦  GPS  3 

H 

M(L-BAND) 

L 

L/M* 

Sj 

INU  ♦  SITAN 

M 

M(C  BAND) 

M  (C  BAND) 

L 

Sa 

INU  ♦  OOR  ♦  S/L 

M 

MfXBANO) 

H/M  (X-BANO) 

M 

Sj 

GPS  3  *  DPR  ♦  BAR 

M 

HfLBANO) 

(X-BANO) 

M  (X  BAND) 

M* 

S6 

GPS  3  ♦  BAR 

M 

M(L  BAND) 

L 

M* 

Si 

INU  ♦  OPR 

M 

L(X  BAND) 

M  (X  BAND) 

L 

Si 

INU  +  S/L 

M 

M(X  BAND) 

H/M  (X  BAND) 

M 

Si 

INU 

L 

L 

L 

M* 

Table  6  Tentative  Premises  for 
Mission  Profile 


•  Ground  AH^OMOt/Cliiiib/Cniiu: 

Judge  INU  (nutUly  {rom  aligiuiMnt  <UiU(A>b*eivablei 

Acoincy,  MbuilneM.  detectibiUty,  wodcload 
lequinnient*  not  demmdiag 

•  Low-LctcI  INGSESS: 

DetectebiJiiy  and  rotnatnen  are  primarily  navigatum 
coocema 

Pilot  attentiao  to  navigation  diagnoaia  limited 

Accuracy  lequiiementa  not  atringent 

•  Pre-IP/IP: 

Navigation  awaicneaa  peaka 

Accuf^  —  aa  it  affecta  bombing  ayalem  peifonnance 
—  ia  prim^  concern 

Critical  deciaion  point  for  apdarin^moding  navigation 
ayatem  or  cbooaiiig  alternative  deliveiy  profile 

e  Poad-nVAMaek: 

Aaaume  NAV  ayatem  working  aa  confirmed  at  IP 
unleaa  told  otherwiae 

No  lime  for  diagnoaia 

•  EGRESS; 

Generally  more  relaxed  navigation  requiremema 

A  few  pointa  where  reliable  navigalian  ia  important 


Field  data  (e.g.,  jam  tolerance,  leacquisition 
characteristics)  relat^  to  GPS  perfbimaiKe  in  a 
jamming  environment  was  not  available  to  the 
ATN  program  due  to  classification  restrictions. 
The  ATN  qtproach  was,  therefore,  to  build  unclas¬ 
sified  jamming  scenarios  and  to  use  high-fidelity 
simulation  to  derive  performance  characteristics 
data  to  support  ATN  design  and  evaluation. 

Event  Diagnosis  —  A  Causal  Network 
knowledge  representation  scheme  was  adopted 
for  the  Event  Diagnosis  Expert.  An  example  net¬ 
work  is  shown  in  Figure  6.  The  network  is  an  ex- 
tri^lation,  assuming  full  Expert  Navigation 
System  conununication  between  ships  and  avail¬ 
ability  of  two  navigation  solutions  (aided  and  un¬ 
aided  INS)  within  a  single  aircraft.  Interpretation 
of  the  network  probabilities  is  shown  in  Figure  7 
along  with  an  example  set  of  probabilities.  These 
values  represent  a  baseline,  engineered  from  de¬ 
signer  judgment  about  the  evidence  values  of  the 
variables  in  the  network. 


Figure  6  Causal  Network  for 
GPS-Aided  INS 


These  premises  were  refined  through  the 
crew  interviews  and  were  then  codified  as  the 
weighting  parameters  prc"ided  in  Table  7.  These 
weightings  were  assigned  by  designer  judgment 
to  reflect,  for  example,  that  detectability  and  ECM 
susceptibility  are  greater  concerns  than  accuracy 
or  workload  reduction  during  ingress.  Similarly, 
the  crews  confirmed  that  navigation-relat^ 
workload  would  be  unacceptable  di^g  the  post- 
IP/attack  phase. 


Table  7  Mission  Manager  Weightings 


MODE 

^-*...,.^RIBUTES 

MISSION 

PHASE 

ACCURACY 

SUSCEniBILITY 

DETECT  ABILfTY 

WORKLOAD 

Ground,  Climb.  Cruise 

.4 

4 

.1 

,1 

Low-Level  bifresi 

2 

3 

3 

2 

Pit  IP/IP 

5 

1 

1 

X 

PDti'IP/AitBck 

0 

0 

0 

0 

EirtM 

2 

.3 

.3 

.2 

O-OMSS 


•  "o  -  V(»j  IA,)  ^  "u  ■  I 


COMPARE 

DO  NOT  COMPARE 

0000 

.9 

.1 

•AO 

.3 

.7 

Figure  7  Event  Diagnosis  — 

Baseline  I^bability 

Most  of  the  knowledge  of  the  Event  Diagno¬ 
sis  module  had  to  be  engineered  since  the  naviga¬ 
tion  suite  of  ATN  does  not  yet  exist,  and, 
therefore,  no  one  is  conversant  with  related  trou¬ 
bleshooting  procedures.  Nevertheless,  the  mod¬ 
ule  design  adtqned  and  generalized  the  techniques 
that  present  day  flight  crews  use  to  di^ose  navi¬ 
gation  problems.  Tliese  techniques  (in  particular 
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ftom  F-16C  and  F-4  ciew  discussions)  utilize 
crosschecking  finmi  sh^  to  ship. 

PVI  Manager — Knowledge  within  the  PVI 
Manager  consists  of  heuiistically-assigned  values 
for  the  display  poiods  (timeouts)  of  ENS  dia¬ 
logue  icons  a^  automatic  display  modes.  The 
time-outs  were  determined  by  the  module  design¬ 
er  based  on  discussions  witii  F-16C,  F-4E,  and 
FB-111  crews;  the  values  so  chosen  are  provided 
in  Table  8.  As  indicated  in  the  table,  more  time  is 
assumed  available  for  crew-ENS  interaction  dur¬ 
ing  the  ground/cruise  and  egress  mission  seg¬ 
ments  than  during  ingress  and  pre-IP  phases. 


Table  8  Baseline  Timeouts  —  Seconds 


'-^^WSSION  PHASE 

ICON  TYPE 

GROUND-CRUISI 

INGRESS 

PRC  IP 

ATTACK 

EGRESS 

Eveni  Diagnosis  Request 

20 

10 

10 

- 

20 

Moding  Advisoiy 

20 

10 

10 

- 

20 

Waypoint  Prompt 

60 

30 

20 

- 

60 

ENS  Development  and  System  Integration 
—  The  ENS  was  develqied  using  the  Activation 
Framework  paradigm  (Ref  1)  to  provide  a  com¬ 
munication  and  control  mechanism  for  all  event- 
driven  functions  with  links  to  clock-driven 
objects.  Some  important  features  of  this  paradigm 
are:  message  passing  between  Activation  Frame¬ 
work  moddes  (AFs),  scheduling  of  clock-driven 
functions  that  are  not  AFs,  and  a  bridge  mecha¬ 
nism  that  allows  communication  between  clock- 
driven  functions  and  AFs.  The  six  experts  of  the 
ENS  are  shown  in  Figure  8  with  a  distinction 
made  between  AFs  and  the  one  non-AF  expert. 
This  paradigm  facilitated  modular  desi^  and  de¬ 
velopment,  real-time  scheduling  efficiency,  and 
effective  focus  of  attention. 

The  ENS  modules  were  developed,  verified, 
and  validated  individually;  the  modules  were  then 
integrated  into  the  ATN  integratitm  enviroiunent 
one  at  a  time.  Upon  completion  of  ENS  integra¬ 
tion,  system  testing  of  the  ENS  was  performed,  in- 


Fignre  8  ENS  Architecture 


eluding  simulated  network  traffic.  In  this 
envirotunent,  traffic  to  and  from  the  network  was 
emulated  by  scrqrts  and  output  files.  The  test 
scripts  included  messages  to  perform  a  full  initial¬ 
ization,  a  replan  following  a  new  threat  report,  and 
routine  functions  such  as  waypoint  checks  and 
diagnoses.  Ouqrut  files  were  reviewed  to  establish 
proper  ENS  fimetioning  and  message  passing  to 
the  bridge.  Upon  successful  completion  of  the 
ENS  integration  and  testing,  the  ^S  was  inte¬ 
grated  with  die  BNS  for  verffication  and  fimetion- 
al  evaluation. 

The  resulting  ATN  Real-Time  Testbed  is 
shown  in  Figure  9.  The  system  was  hosted  on 
commercially-available  platforms — the  environ¬ 
ment  file  (ou^ut  of  the  E/SS)  and  BNS  on  a  VAX 
6310,  the  ENS  on  a  VAXStation  3100.  A  single 
VAX  Common  LISP  process  implemented  die 
ENS  software;  ENS  modules  were  implemented 
within  individual  Common  LlSPpackages.  Com¬ 
munication  among  the  processors  was  via  ether- 
net  (VAX  to  VAX)  and  serial  port  ^AX  to  PC). 
Key  functionality  provided  by  this  testbed  in¬ 
cludes  a  six  degree-of-freedom  aircraft  simula¬ 
tion,  high  fidelity  sensor  and  threat  models,  full 
BNS  and  ENS  implementations,  simulated  cock¬ 
pit  displays,  and  an  engineering  interface.  The 
testbed  was  used  for  subject-interactive  evalua¬ 
tion  of  ATN  and  as  a  staging  platform  for  integrat¬ 
ing  ATN  into  a  real-time  cockpit  simulator. 

Testing  of  the  integrated  ATN  system  re¬ 
vealed  processing  botdenecks  that  impaired  real¬ 
time  performance.  In  the  interest  of  developing 
general  software  technology  for  real-time  intelli¬ 
gent  system  implementation,  refinement  of  the 
ATN  system  was  performed.  This  included  de¬ 
creasing  the  frequency  of  navigation  resource 
planning  in  the  Mission  Manager  to  one  mode 
change  per  leg,  reducing  the  numerical  precision 
of  the  jammer  power  calculations,  and  replacing 
backward  chaining  inferencing  in  Ae  System  Sta¬ 
tus  expert  widi  tables  (the  original  form  of  the 
knowledge).  Execution  speed  of  the  ENS  was  in¬ 
creased  and  real  time  operation  was  achieved. 

Partitioning  of  processing  during  die  engi¬ 
neering  development  provided  a  single  ENS  haid- 
ware/software/communications  implementation 
that  was  compatible  with  both  the  engineering 
testbed  and  cockpit  simulator  installation.  This 
“plug  compatible’'  implementation  enabled 
upgrading,  refining,  and,  when  necess^, 
troubleriiooting  in  Ae  engineering  installation. 
Thus,  cockpit  simulator  time  was  reserved  for 
cockpit  display  development  and  evaluation  test¬ 
ing. 

Rehosting  to  Cockpit  Environment  —  The 
cockpit  integration/evaluation  was  pursued  as  a 
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Flsnre  9  ATN  Real-Time  Testbed 


joint  effott  with  subcontractor  General  Dynamics/ 
Fort  Worth  Division  (GDFW).  The  ATO  installa¬ 
tion  was  sited  in  a  GDFW  24  ft  Dome;  an 
overview  of  the  intention  is  shown  in  Figure  10. 
Much  of  the  integration  was  derived  from  existing 
F-16C  simulator  functicnudity.  The  main  simula¬ 
tion  processors  host  the  airfirrae  dynamics/flight 
control,  sensor  models  and  simulate  fire  control 
computer  processing.  The  main  processor(s)  also 
provide  stroke-text  to  die  displays  and  I/O  inter¬ 
faces  to  other  ^tecialized  processors.  Out-of¬ 
cockpit  and  IR  imagery  were  processed  by  an 
Evans  and  Sutherland  CT6  scene  generator.  Radar 
imagery  was  derived  from  Digital  Radar  Land 
Mass  System  (DRLMS)  data. 

A  number  of  modifications  to  the  ATN  sys¬ 
tem  were  implemented  to  make  the  system  suit¬ 
able  for  integration  into  the  F-16  codrpit 
installation.  Amrnig  these  modifications  were: 

Reduced-order  navigadtm  models  to  serve  as 
a  BNS  (INS,  GPS,  SITAN,  RADAR/EO) 

Exclusion  of  the  Navigation  Source  Manager 
fixmi  the  cockpit  integration 

Integration  of  fully  automatic  displays  Elimi¬ 
nation  of  Waypoint  and  Event  Diapiosis  re¬ 
quests 


Addition  of  timeouts  for  advisories  (while 

flashing)  to  alert  the  pilot  of  mode  changes. 

ATN  SYSTEM  EVALUATION 

Evaluation  of  the  ATN  system  was  performed 
in  two  phases:  the  Engineering  Evaluation  Phase 
conducted  in  the  real  time  engineering  laboratory 
at  TASC,  and  the  Cockpit  Evaluation  Phase  con¬ 
ducted  in  an  F- 16  dome  at  GDFW.  The  two  evalu- 
atimi  phases  ate  summarized  below: 

Engineering  System  Evaluation 

In  the  Engineering  Evaluation  Phase,  naviga¬ 
tion  systm  performance,  resource  management, 
pilot  workload,  and  the  pilot/mission  interface 
were  evaluated  with  and  without  ATN  assistance. 
Subjects  for  these  tests  were  TASC  engineers,  two 
of  whom  were  former  rated  military  personnel 
with  experience  in  high  i^rfotmance  aircraft. 
This  ph^  of  testing  us^  tdgh  fidelity  models  of 
the  navigation  sensors  and  the  types  of  (tegrada- 
tions  to  which  they  are  vulnerable.  The  computa¬ 
tions  required  to  execute  these  models  dictated 
that  they,  and  the  trajectory  of  the  aircraft,  be  pre¬ 
computed  before  the  real  time  testing.  The  accura¬ 
cy  of  these  models  allowed  die  evaluation  of 
different  techniques  for  the  detection  tuul  evalua¬ 
tion  of  sensor  flutes  and  external  interference. 

Since  the  aircraft  flight  path  was  precom¬ 
puted,  a  target  desigtwtion  secondary  task  was 
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G-1T2I2 


Figure  10  ATN  Cockpit  Integration 


incorporated  as  part  of  the  real  time  testing  to  sub* 
sdtute  for  actuid  crew  workload.  The  secondapr 
task  display  and  scoring  system  are  presented  in 
Figure  11  and  Table  9.  A  Ml  description  of  the  ex¬ 
perimental  medtod  is  provided  in  Reference  1. 
The  primary  objectives  of  this  phase  were  to  in¬ 
vestigate  the  behavior  of  ATN  in  a  subject-inter¬ 
active  mode  and  to  determine  ATN  effectiveness 

o-in«t 

>-4-W 


Figure  11  Out  of  Cockpit  Scene  and 
Secondary  TiA 


in  detecting  and  responding  to  sensor  failures. 
Key  evaluation  results  include; 

The  ATN  system  detected  and  properly  re¬ 
sponded  to  a  variety  of  mission  and  system 
events  including  failures,  threat  warnings, 
and  m^  errors 

The  system  interface  with  the  crew  was  not 
totally  satisfectory;  further  refinement  was 
required  brfore  the  cockpit  evaluation  j^ase 

The  ATN  system  provided  optimal  moding, 
response  to  environment  chants  (i.e.,  m- 
biiefed  jammers)  and  resolution  of  pilot 


Table  9  Secondary  Task  Scoring 


ICON 

NEUTRALIZATION  SCORE 

# 

- - 

\ 

o 

2 

<  > 

0 

u 

U(b.2)i  I  ilb  s  3 

0 

o 

•5 
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observed  anomalies  (e.g.,  mi^laced  way- 
points). 

Moding  decision  errors  were  common  in 
manual  mode,  particularly  with  respect  to 
emissions  management  arid  over-conservat¬ 
ism  (e.g.,  downmoding  in  response  to  a 
missed  w^poim). 

Cnflkpit  Simulatw  BvaliMrim 

The  second  phase  of  evaluation.  Cockpit 
Evaluation,  was  performed  in  an  F-16  Dome  in 
the  Flight  Simulation  Laboratory  at  GDFW.  In 
diis  phase,  the  functitmality.  crew  ittferface,  and 
mission  utiliQr  of  ATN  were  evaluated  in  a  simu¬ 
lated  (^terational  setting. 

The  ATN  engineering  effort  and  evaluation 
provided  essential  groundwork  for  rehosting  and 
evaluating  ATN  in  an  F-16C  coclqrit  simidator. 
The  objectives  of  the  cockpit  integratitm  and  eval¬ 
uation  were  to: 

Exercise  the  ATN  system  in  a  realistic  task 
envirmunent 

Obtain  subjective  data  on  ATN  utility  and 
mission  effectiveness 

Integrate  ATN  displays  into  a  military  stan¬ 
dard  layout 

Assess  Refinements  and  System  Personaliza¬ 
tion 

A  conventional  navigation  mode  manager 
was  implemented  for  comparismi  purposes.  This 
manager  was  an  extri^lation  of  current  practic¬ 
es,  using  table-driven  moding  based  upm  filter 
covariance  values  and  certain  coclq>it  switch  set¬ 
tings  (i.e.,  "RF  silent”). 

A  challengiiig  mission  (Figure  12)  was  de¬ 
signed  that  involved  a  40  minute  ingress  to  attack 
a  defended,  known  location  target.  Sector  jam¬ 
mers  were  d^oyed  as  shown  to  induce  failures  of 
GPS  during  ingress  and  to  preclude  use  of  GFS 
during  the  target  attack.  The  target  was  a  rail 
bridge  crossing  a  river,  having  no  distinctive  col- 
latmal  features  to  aid  location.  A  combination  of 
simulated  air  defenses  forced  most  of  the  mission 
to  be  flown  at  low  levels.  Varying  visibilities 
forced  relUnce  on  sknulated  EG  systems.  EW 
threats  combined  with  variidde  terrain  roughness 
fnevented  total  reliance  on  either  GPS  or  terrain 
aided  navigation.  The  mission  and  threats  were 
vtfied  to  assess  the  relative  strengths  of  the  ATN 
system  and  the  conventional  system  over  a  range 
of  conditions. 


Figare  12  ATN  Edwards  Gaming  Area 


Tests  were  conducted  at  the  GDFW  facility 
during  die  last  three  months  of  1989.  “Pdots”  for 
these  missions  included  contractor  engineers  and 
pilots  and  rated  US  Air  Fbrce  participants.  Dtiring 
these  tests,  the  system  interface  with  the  crew  was 
simplified,  and  a  lag  filter  fault  detection  concept 
was  implemented  evaluated. 

The  availability  of  precision  navigation  dur¬ 
ing  the  mission,  either  from  the  conventional  sys¬ 
tem,  or  from  die  ATN  system,  made  a  noticeable 
imi»ovement  in  the  crew’s  ability  to  avoid  threats 
and  engage  the  target.  A  significant  benefit  dem- 
(Mistrated  by  ATN  was  in  sensor  cuing.  By  main¬ 
taining  high  accuracy  navigation  into  the  attack 
phase  of  the  musion,  direct  accpiisition  of  the  tar¬ 
get  was  pomble  us^  only  the  EO  targeting  pod. 
This  cqiability  obvia^  die  need  for  fost  acquir¬ 
ing  the  target  with  radar,  thereby  reducing  both 
emissions  and  required  workload  in  the  attack 
{diase.  The  conventional  moding  system,  by  con¬ 
trast,  was  vulnerable  to  countermeasures  in  the 
terminal  area. 

The  cockpit  simulator  evaluation  was  accom¬ 
plished  in  a  dim  cycles  of  testing  and  refinement. 
The  ^cles  were  accomplished  over  a  six  week  pe¬ 
riod  in  three  installments  of  one  week  of  tests  fol¬ 
lowed  by  a  week  of  data  analysis  and  system 
refinement.  2-3  pilots  per  cycle  participated.  Fol¬ 
lowing  the  final  tests,  a  dmonstration  was  pro¬ 
vided  for  the  Government 

Significant  revision  of  the  pilot  interface  was 
required  as  a  result  of  the  Cycle  1  tests.  Initial 
feedback  relative  to  displays  was  sufficiendy 
strong  that  it  dmninated  the  subjective  results 
from  these  tests.  The  team  response  was  to  partial¬ 
ly  revise  the  disfdays  imor  to  the  final  ^cle  1 
tests,  complete  die  revisions  for  Cycle  2,  arid  per¬ 
form  two  additkmal  in-house  tests  for  formal  data 
collection. 

Given  the  relatively  small  sample  of  subjects 
(four  GD  and  two  Air  Force  pilots)  trends  reported 
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ntt  inteipietations  of  the  evaluation  team.  Rq>ie- 
sentative  enor  traces  and  we^MD  accuracies  were 
obtained  to  illustrate  die  tren^. 

PROGRAM  RESULTSAJSSONS  LEARNED 

Conclusions  reached  as  a  result  of  the  ATN 
program  qjian  a  broad  mge  of  tqncs,  reflecting 
die  equally  large  range  of  issues  wldressed  in  de- 
signing,d^dof»ng.andevahuttingtheATNsys- 
mm.  results  and  lessons  learned  are  presented 
in  diis  section.  Additional  details  are  provided  in 
Refnence2. 

Pimcrinnalitv  —  A  reasonaUe  set  of  func- 
tions  was  sdected  for  die  ATN  system  to  perform. 
The  functions  diosen  all  fulfilled  dieir  requited 
supprnt  roles  as  members  of  the  ATN  “communi¬ 
ty”  and  included:  fault  detection,  handlitig  unex¬ 
pected  occurrences,  using  redundant  information, 
and  real-time  jdannirtg/i^anning. 

The  real-time  fdarmiiig/replanniitg  function 
distinguishes  ATN  from  current  ti^le-driven 
modi^  algoridims.  ATN’s  Mission  Manager  uses 
an  on-board  model  of  the  mission  and  navigation 
requirements  to  andcqiate  and  configure  the  navi¬ 
gation  system  for  chides  in  environmem,  navi¬ 
gation  requirements  (Le.,  required  accuracy, 
emissions,  constraints,  and  available  crew  work¬ 
load),  and  equipment  status.  By  contrast,  the  table 
driven  rqiproadies  rely  on  sensor  diagnostics 
(e.g.,  GI%  receiver  status),  alone,  to  d^rmine 
changes  in  mission  environment  and  inedeter- 
mined  logic  to  detetmine  moding.  The  iW-time, 
model-ba^  anticqMtioo  of  the  ATN  provides  a 
significam  defense  against  environmem- induced 
sensm  data  cornqption,  mappmpattc  emissitms 
managemern  and  increased  pilot  workload. 

A  single  self-consistency  Kalman  filter  for 
GPS  measurements  was  effective  in  detecting 
GPS  degradation.  Similarly,  a  lag  filter  for  a  “san¬ 
ity  chedc”  provided  notic^le  benefits  in  avoid¬ 
ing  use  of  cornqxed  data. 

A  significam  observatirm  was  that  there  is  an 
absolute  requiremem  for  a  fault  tolerant  inertial 
data  source  if  one  is  to  realistically  meet  mission 
requirements  for  an  IMC  imerdictitMi  mission.  As 
more  teal  w<^  experience  becomes  available 
with  advanced  sensors,  it  will  be  worthwhile  to  re¬ 
investigate  fault  detection  using  a  combination  of 
system-level  and  low-level  deep  knowledge  tech¬ 
niques. 

Real^ma  Inferenciny.  Pktming  TyJiniqiiea. 
and  Knowledae  Stmctmea  —  All  of  the  para¬ 
digms  chosra  and  devdoped  for  the  individual 
experts  performed  well,  given  the  currern  state  of 


the  knowledge  base.  As  ATN  functionality  ex¬ 
pands,  some  modificatkms  or  extension  of  these 
paradigms  may  be  qipropriate. 

Key  elements  of  the  successful,  real-time 
ATN  imegratitm  from  an  architectural  statK^int 
include: 

Partitioning  of  syiKhronous  and  asynchro¬ 
nous  c(»ipotations  into  sqiarate  processors. 

Distributing  control  of  the  ATN  system  using 
the  Activation  Frameworir  Paradigm. 

Reasoning  about  time  —  in  particular,  per¬ 
forming  localized  rqilanning  in  die  Mission 
Manager  and  reasoning  about  time  costs  of 
acquiring  information  in  Evrot  Diagnosis. 

Using  table  lookup  procedures  rather  than 
rules  when  warranted  for  efficiency. 

Using  the  Activation  Framework  ^^oach 
obviated  efficiency  problems  associated  with  ar¬ 
chitectures  that  use  a  blackboard  and  centralized 
controller.  In  addition,  use  of  messages  and  a 
structure  of  message  priorities  significandy  facili¬ 
tated  modularization  and  eventual  integration  of 
the  system  while  providing  flexibility  of  module 
devel<qnnent. 

Distribution  of  Imdliyence  ^  Intelligence  is 
best  mantled  if  it  is  qiecific;  to  the  extent  possi- 
Ue,  intelligence  and  knowledge  should  be  parti¬ 
tioned  into  specialized  domains  that  coc^rate 
effectively.  Mdiin  die  ATN  system,  intelligence 
was  distributed  according  to  die  following  pMos- 
qihy:  Levels  of  abstractitm  generally  are  decided 
^  die  type  of  information  used;  lower  level  func¬ 
tions  may  use  raw  sensor  data  while  higher  levels 
use  derived  information. 

Crew  Interface — ATN  evaluation  results  in¬ 
dicated  diat  pilots  want  die  navigation  syston  to 
be  rdiable,  accurate,  and  to  work  in  the  back¬ 
ground.  Crw  accqitsnce  of  what  the  ATN  system 
was  doing-along  with  qipropriateness  of  the 
“touch  and  feel’  aspects~^v«j  to  be  crucial  for 
system  success.  In  response  to  strong  recommen¬ 
dations  from  pilot  evduators  of  the  ATN  system, 
the  recommended  ATN  crew  interface  consists  of: 


A  HUD  di^ay  showing  the  current  naviga¬ 
tion  mode  and  warning  or  cautkm  status,  if 
active  (diese  di^lay  elements  flash  for  5  sec¬ 
onds  following  a  change  of  mode  or  status). 

A  moving  mq>  which  serves  as  a  navigation 
aid  and  a  threk  situation  display. 

A  status  page  piesaiting  the  current  mode 
status,  results  of  die  last  cross-diedc,  and  ac¬ 
curacy. 
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Knnwladge  Attpiiririnn  —  Knowledge  ac¬ 
quisition  was  ooe  of  the  most  challenging  aq)ects 
of  ^  ATN  system  deagn  and  development.  The 
wide  range  of  requited  knowledge  areas  and  lack 
of  user  experience  with  advanc^  avionics  sub¬ 
systems  necessitated  die  use  of  a  combination  of 
i^ysis,  shnulation,  extrapolation,  and  intuition, 
in  addition  to  traditicmal  knowledge  acquisition 
tedmiques.  hi  qiecific  cases,  sul^stem  model 
simulatitms  with  expert  interpretation  of  results 
provided  an  important  bti^e  between  current  ex- 
perioice  and  {Hojected  systm  bdbavior.  Key  in 
this  aqiect  was  the  ability  to  simulate  GPS  in  jam¬ 
ming  scenarios.  Knowledge  acquisition  experi¬ 
ences  also  emphadzed  die  value  of  having 
simulation  to<ds  available  early  and  being  able  to 
affordably  tun  diem  ftequendv  for  the  purposes  of 
expanding  and  validating  the  knowledge  base. 

An  organized  pre-brief  and  mission-centered 
quesdotmaire  were  essential  to  efficient  discus- 
sums  with  the  aircrews.  Gaining  familiarity  with 
the  aircrew’s  systems,  tacdcs,ai^  vocabulary  uid 
being  able  to  idate  these  to  the  ATN  sensor  suite 
and  mission  paid  large  dividends  during  the  mter- 
views  and  knowledge  analysis  {diases. 

System  Developmtgit — The  traditional  sys¬ 
tem  d^elofment  qiproach  used  in  the  ATN  pro¬ 
gram  had  significant  drawbacks.  It  required  ail 
functions  to  be  ^lecified  at  a  uniform  level  of  de¬ 
tail  regardless  of  the  actual  maturity  of  the  algo¬ 
rithms.  Many  of  die  selected  AI  paradigms  had 
never  been  imidememed  in  an  avionics  qjplica- 
don.  The  significant  documentadon  burden  di¬ 
verted  resources  awa,  fiom  early  prototyping  tuid 
design  risk  reduction.  Much  of  the  eaAy  docu¬ 
mentadon  became  obsolete  due  to  design  changes 
that  were  required  afta*  attempting  to  implemoit 
the  fiincdons.  The  qiiral  model  of  software  devel¬ 
opment  that  has  rec^y  qipeared  in  the  literature 
appears  to  offer  a  sounder  basis  for  development 
of  a  ^stem  of  this  nature  than  the  waterfall  model 
that  the  ATN  project  used.  Documentation  that  is 
an  asset  rather  dun  an  impediment  to  a  project  of 
this  nature  requires  ahigh  (periuqis  Utopian)  level 
of  honesty,  technical  competence,  trust,  and  dar¬ 
ing  on  boA  the  Govemmern  and  contractor  sides. 

The  phasing  of  knowledge  acquisidon  inter¬ 
views  could  also  be  modified  to  support  a  spiral 
development  approach.  Discussions  early  in  the 
post- requirements  definition  phase  would  be  use¬ 
ful  to  he4>  focus  funcdoniu  development  and 
knowledge  acquisifrm  fdanning.  A  second  round 
ofknowl^e  acquisition  would  be  smytwted  by  a 
fiist  prototype;  some  levd  of  interaction  widi  this 
prototype  would  siqifdement  the  mission-cent¬ 
ered  nuerviews. 


Gnmpiiter  —  CommtXI  LISP 

proved  to  be  a  good  design^prototyping  language 
for  the  ATN  effort.  A  language  offering  greater 
control  of  memory  management  would  be  desir¬ 
able  for  future  develqpmenifimplementadmi  of 
nnbedded  systems  ^iplicadtms. 

Wcaptm  PdiYwy  Capabilities  —  Continu¬ 
ous  high  accuracy  navigadon  (<80  m^rs)  sub¬ 
stantially  improved  the  crew’s  ^ility  to  engage  a 
prdirie^  target  in  IMCctmdidcms  when  using  an 
EO  pod  and  eliminated  the  need  to  use  die  att^ 
radar  as  part  of  the  target  acquisidon. 

Navigadon  System  Management  —  A  navi¬ 
gadon  management  system  that  suiqilemented  the 
standard  algorithmic  techniques  with  symbolic 
knowledge  about  the  system  components,  threats, 
and  missitm  as  factors  in  its  execudon  produced 
measurably  better  navigadon  performance.  De¬ 
velopment  of  diis  system  manager  required  the 
use  of  a  broad  range  of  Al-based  structures. 


SUMMARY 

The  ATN  project  was  intended  to  investigate 
the  utility  of  intelligent  system  management  for 
integrate  navigadon  on  a  next  generation  combat 
aiic^.  Significant  insist  was  gained  into  the 
suitability  of  current  AI  paradigms  and  software 
development  techniques  for  a  project  of  this  na¬ 
ture.  The  results  and  experiences  during  this  proj¬ 
ect  indicated  diat  such  an  imelligent  system 
manager  could  produce  a  measurable  benefit  in 
die  red  world.  This  benefit  diould  become  even 
mote  significant  as  operadonal  users’  experiences 
yield  a  better  understonding  of  the  actual  behavior 
of  the  next  generadon  of  navigation  sensors. 
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Discussion 

1.  D.  Bosnian,  Netherlands 

Kalman  filters  of  different  design  and  manufacture  may  have 
differing  signals  delays.  For  a  federated  system,  it  must  be 
assumed  that  all  data  originate  from  the  same  time-slice.  Are 
the  delay  differences  sufficiently  small  to  be  disregarded? 

Author: 

Since  the  ATN  program  was  a  proof  of  concept  for 
intelligent  management  techniques,  our  navigation 
simulation  was  not  so  detailed  as  to  include  simulation  of 
time  offsets  between  sensors  or  between  the  Kalman  filters 
associated  with  the  sensor.  In  an  actual  system 
implementation,  these  differences  should  not  be  ignored.  In 
our  organization,  these  issues  are  being  addressed  by 


advanced  Kalman  filter  efforts  rather  than  system 
management  efforts. 

2.  H.  Timmers,  Netherlands 

How  much  from  the  developed  system  eventually  was  rule 
based  and  how  much  “switch-logic"  or  table  driven? 

Author: 

I  would  estimate  that  the  knowledge  based  components  of 
the  ATN  expert  modules  are  approximately  50%  rule  based 
and  50%  table  look-up  and/or  algorithmic  (i.e., 
“conventional”  techniques).  The  Mission  Manager  and  the 
System  Status  Expert  are  both  primarily  rule  based.  The 
Pilot  Vehicle  Interfare  Manager  and  the  Moding  Expert  use 
more  conventional  techniques,  while  Event  Diagnosis  and 
the  Navigation  Source  manager  are  a  combination. 
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1.  SUMIARY 

Neural  network  software  simulations  for 
the  representation  and  prediction  of 
aircraft  Inertial  navigation  system 
(INS)  data  were  developed.  These 
simulations  were  evaluated  using  flight 
test  data  that  sampled  INS  outputs  at  a 
standard  rate  for  neural  network  test¬ 
ing  and  at  half  this  rate  for  neural 
network  training.  The  simulations  used 
both  locally  linear  neural  networks  and 
backpropagatlon-tralned  neural  net¬ 
works.  Locally  linear  neural  networks 
have  several  desirable  properties  for 
this  application.  Including  Interpola¬ 
tion  of  the  training  data  and 
representation  of  linear  relationships. 
For  the  flight  test  data  two  mil- 
llradlan  testing  accuracy  was  generally 
achieved  with  five  successive  and  prior 
INS  heading,  pl^ch,  and  roll  Increments 
as  inputs. 

2.  LOCALLY  LXMKAR  NRDRAL  NRT1V0RK 
(LUOf)  CBARACTSRX8TXC8 

Multilayer  feedforward  neural  networks 
that  use  backpropagatlon  [Rumelhart, 
Hinton,  and  Williams,  1986]  or  similar 
training  algorithms  are  by  far  the  most 
consnon  In  engineering  applications. 
However,  these  neural  networks  have 
several  limitations.  First,  they 
generally  lack  the  coordinate  In¬ 
variance  property,  according  to  which 
the  testing  output  Is  unchanged  If  the 
testing  and  training  (or  data)  Inputs 
are  translated,  rotated,  or  scaled. 
Second,  without  excessive  training  they 
generally  lack  the  data  interpolation 
property,  according  to  which  the  test¬ 
ing  output  Is  the  training  output  if 
the  testing  input  is  the  training  input 
(Poggio  and  Girosi,  1990] .  Third,  they 
generally  lack  the  linear  repre¬ 
sentation  property,  according  to  which 
any  testing  point  is  on  a  linear  sur¬ 
face  if  all  training  points  are  on  this 
surface.  Finally,  they  generally  lack 


the  data  bootstrapping  property,  ac¬ 
cording  to  which  the  testing  outputs 
have  least  squared  error  for  any  train¬ 
ing  points  declared  to  be  testing 
points.  In  contrast,  the  locally 
linear  neural  networks  discussed  below 
have  all  of  the  above  desirable  charac¬ 
teristics  . 

3.  LLMM  ST>OCTDRK  AMD  TRAXMXMG 
ALGORITHM 

Figure  1,  adopted  from  Nielson  [1987], 
gives  an  exan^le  of  the  need  for 
coordinate-invariant  neural  networks. 
Here  an  expression  with  five  adjustable 
coefficients  is  matched  to  five  train¬ 
ing  points.  When  the  scales  of  the  two 
Independent  variables  are  multiplied  by 
different  constants,  interpolation 
using  the  expression  gives  different 
results  for  the  same  testing  point. 

Figure  2  describes  the  setup,  training, 
and  testing  of  locally  linear  neural 
networks  [Gustafson,  Little,  and 
Olczak,  1990] .  There  are  two  essential 
steps  In  training:  transforming  the 
Inputs  to  Invariant  coordinates  and 
finding  a  plane  through  each  training 
point  that  satisfies  a  selected 
bootstrapping  property.  In  testing  the 
plane  through  the  training  point 
nearest  to  the  testing  point  (In  the 
transformed  Inputs)  Is  used  to  find  the 
testing  point  output. 

Figure  3  shows  a  simple  exan^le  of  one 
possible  bootstrapping  procedure.  Here 
for  one  Input  a  line  Is  found  through  a 
training  point  such  that  the  line 
predicts,  with  minimum  squared  error, 
either  one  training  point  transformed 
Into  a  testing  point  or  all  but  one 
training  points  transformed  Into  test¬ 
ing  points. 

4.  XNS  rLXGBT  TK8T  DATA 

Figure  4  shows  typical  F-16  aircraft 
INS  flight  test  data  that  Includes 
heading,  pitch,  and  roll  versus  time. 
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Differences  in  successive  sanities  of 
heading,  pitch,  and  roll  are  to  be  rep¬ 
resented  and  predicted  using  neural 
networks  so  as  to  maintain  the  pointing 
and  tracking  accuracy  of  a  passive  op¬ 
tical  device  detection  system 
[Gustafson  and  Little,  1988] .  Figure  5 
shows  a  typical  plot  of  such  dif¬ 
ferences  between  successive  san^les  of 
pitch  versus  time. 

5.  MKORAL  MimORK  BBPMSIHTATZaM  OF 

ms  DATA 

In  all  cases  data  that  san^led  the  INS 
outputs  at  a  standard  rate  was  used  for 
neural  network  testing,  and  data  at 
half  this  rate  was  used  for  training. 
Figure  6  shows  a  standard 
backpropagation-t rained  neural  network 
representation  of  the  data  in  Figure  5. 
The  neural  network  had  7  hidden  neurons 
and  15  inputs  consisting  of  five  suc¬ 
cessive  prior  heading,  pitch,  and  roll 
increments.  Training  time  on  a  386- 
class  PC  was  approximately  1.5  hours. 
Figure  7  represents  the  same  data  using 
the  same  neural  network  but  with  less 
training.  Note  that  the  "hash"  detail 
of  Figure  5  is  better  represented  after 
a  longer  training  time.  Also  note  that 
the  LLNN  would  represent  all  training 
data  exactly  because  of  the  data  inter¬ 
polation  property. 

6.  NEORAL  NITIIORR  FREDICTIOr  OF  mS 

DATA 

Figure  8  shows  another  plot  of  dif¬ 
ferences  between  successive  san^les  of 
flight  test  pitch  versus  time.  Figure 
9  shows  neural  network  prediction  of 
the  Figure  6  data  using  a  locally 
linear  neural  network  that  was 
bootstrapped  so  that  of  5  nearest 
neighbor  training  points,  all  except 
the  closest  were  transformed  into  test¬ 
ing  points.  Figure  10  shows  prediction 
of  the  Figure  6  data  using  a 
backpropagation-trained  neural  network 
that  had  7  hidden  neurons.  Both  neural 
networks  had  as  inputs  5  successive 
heading,  pitch,  and  roll  increments 
prior  to  a  given  pitch  increment,  and 
both  had  as  output  a  prediction  of  this 
increment.  Figure  11  shows  histograms 
of  differences  between  predicted 
(Figures  9  and  10)  and  actual  (Figure 
8)  pitch  increments  for  the  locally 
linear  and  backpropagation-trained 
neural  networks. 


Figures  8,  9,  and  10  show  that  the  lo¬ 
cally  linear  neural  network  predicted 
more  of  the  "hash"  structure  in  the 

data  than  the  backpropagation-trained 

neural  network.  Figure  11  shows  that 
predictions  using  both  neural  networks 
were  typically  within  0.1  degrees  (1.7 
milliradians)  of  actual  values  and  that 
the  error  distribution  for  the  locally 
linear  neural  network  was  more  sym¬ 
metric  . 
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•  Inteipolaiit  (after  G.  Nlclaoa) 

z(x,y)  =  a  +  bx  +  cy  +  +  e(x^  +  y^) 

•  Peet-mnute  Cooidlnatea 

X  X  £ 

1  1  0 

1  0  0 

•5  .5  I  z(.75,  .5)  =  .875 

0  10 

0  0  0 

a  Inches-Seconda  Coordlaatca 

2X2 

12  60  0 

12  0  0 

6  30  1  z{9 , 30)  =  .990 

0  60  0 

0  0  0 


Figure  1.  Example  of  need  for  coordinate-invariant  neural  networks. 


•  Setup 

1 .  Training  points,  m  in  number,  each  with  n  input  variables  and  one  output  variable. 

2.  One  testing  point  with  n  input  variables. 

•  Training 

1 .  Find  the  centroid  of  the  training  point  input  variables.  Find  the  eigenvalues  and  eigenvectors  of 
the  input  variable  covariance  matrix  (e.g..  using  singular  value  decomposition).  Transform  the 
input  variables  of  all  training  points  to  me  coordinate  system  having  its  origin  at  the  centroid 
and  its  axes  paraUel  to  the  eigenvectors  with  the  axis  scales  in  units  of  the  eigenvalues. 

2.  Find,  using  the  transformed  input  variables,  a  plane  through  each  training  point  that  is  a  least- 
squares  fit  to  the  remaining  training  points.  Eimute  the  least  squares  fit  so  that  more  distant 
points  in  the  input  variables  have  less  weight  in  accordance  with  a  selected  bootstrapping  proce¬ 
dure. 

•  Tcstfaig 

1.  Transform  the  testing  imlnt  input  variables  to  the  coordinate  ^tem  obtained  in  training  step  1. 
Using  the  transforms  input  variables,  find  the  training  point  mat  is  nearest  to  the  testing  point. 

2.  Find  the  plane  from  training  step  2  throu^  this  nearest  training  point.  Find  the  testing  point 
output  vmiable  as  the  intersection  of  this  plane  with  the  transformed  testing  point  input  vari¬ 
ables. 


Figure  2.  Locally  linear  neural  network  setup,  training,  and  testing. 
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Given  thiee  dau  points  ***** *0  *1  ^  *2-  **”*  “  ***”*“«**  *****  **«***'*• 

with  expected  value  of  the  mean  squared  error,  the  y  value  or  values  indicated  below  when 

one  of  two  equally  Uktly  events  occurs: 

(1)  Local  event  -  y^  is  lost  (I.e..  the  y  value  of  the  nearest  neighbor  of  Xq  Is  lost). 

(2)  Global  event  -  y  |  and  y2  are  lost  (I.e..  the  y  values  of  ail  neighbors  of  Xq  are  lost). 

o  Solnttoa 

The  slope  b  of  the  required  line  Is  determined  so  as  to  minimize  the  sum  of  squared  errors  S: 

s  -  lyg  +  bu,  -  *o>  ■  yi*^  ♦  iiyo  ♦  *>‘*1  -  V  ■  ♦  lYo  ♦  **<*2  •  *0*  ■ 

The  soluUon  with  yj  -  yg  •  Vj  .  y^  -  y^  »  v^  .  Xj  -  Xq  »  Uj  .  -  Xq  =  U2  is: 

b  =  (3 VjUj  ♦  VjU^I/OUj^  +  u^^l 
This  result  may  also  be  obtained  as  the  least  squares  solution  of; 

yi  -yo’****!  *0* 
yi  -yo’*'**!  •*o» 
yi  -yo'****!  *o> 
y2  yo  =  ‘’‘*2  -*o> 


Figure  3.  Simple  example  of  one  possible  bootstrapping  procedure. 


Time  (sec) 

Figure  4.  Typical  F16  aircraft  INS  flight  test  data. 
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Figure  5.  Differences  between  successive  sait^les  of  flight-test  aircraft 
pitch  angle  versus  time. 


Figure  6.  Neural  network  representation  of  Figure  5  data  (backpropagation 
training  with  7  hidden  neurons  and  5  successive  prior  heading, 
pitch,  and  roll  increments  as  inputs) . 
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Figure  9.  Locally  linear  neural  network  prediction  of  Figure  8  data  (5  suc¬ 
cessive  prior  heading,  pitch,  and  roll  increments  as  inputs;  5 
neatest  neighbor  training  points  bootstrapped  so  that  all  except 
closest  were  transformed  into  testing  points) . 
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Figure  10,  Backpropagation-trained  neural  networJc  prediction  of  Figure  8  data 
(5  successive  prior  heading,  pitch,  and  roll  increments  as  inputs; 
training  with  7  hidden  neurons. 
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Figure  H.  Histograms  of  differences  between  predicted  (Figure  9  and  10)  and 
actual  (Figure  8)  pitch  increments  for  locally  linear  and 
baclcpropagat ion-trained  neural  networlcs. 
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1.  SUMMARY  / 

The  Pilot's  AsMciate  ^ograin  has  completed  its 
first  phase  of  nmctio|ial  devenpment  which 
included  two/signifi/ant  pro^am  milestones: 
Demonstra^n  2  ana  Demonjnration  3.  The 
early  successful  dwelopment  of  complex, 
knowledgehbased/ decisioiyaiding  systems 
allowed  the  progs^  to  shift  focus  to  a  more  near- 
term,  embedded^avionics  application  of  the 
technology.  This  change  in  philosophy  forced  an 
evolution  away  from  a  program  designed  to 
explore  artificial  intelligence  without  processing 
bounds,  towards  a  niore  realistic  prototyping  of 
functionality  consistent  with,  and  constrained 
by,  the  realities  of  an  avionics  processing 
architecture  of  an  at.  tual  aircraft.  This  paper 
focuses  one  of  the  unique  developmental 
approaches,  the  technical  progress  made  through 
this  phase  of  the  program,  and  the 
accomplishments  and  disappointments  with  the 
design  approach.  I  astly,  a  brief  look  into  the 
lessons  learned  as  artificial  intelligence 
technology  was  applied  to  a  d3mamic  and 
complicated  domain  will  be  presented.  ^ 


on  processing  architecture.  In  fact,  creating  a 
technology  pull  for  Strategic  Computing  by 
establishing  new  processor  requirements  was  a 
fundamental  desire.  However,  after  the 
resounding  success  of  Demonstration  2,  both 
technical  and  operational,  DARPA  directed  a 
shift  in  philosophy  towards  near-term  avionics 
processors  specific  to  an  existing  or  planned 
aircraft.  This  shift  away  from  the  unbounded 
processing  world  of  Strategic  Computing  forced 
associated  shifts  in  functionality  scoped  by  the 
bounds  of  limited  avionics  processors,  both  in 
capability  and  availability  in  the  selected 
aircraft.  The  new  philosophy  was  to  use  the 
remainder  of  Phase  1  to  develop  Pilot's  Associate 
as  a  fully  functional,  nonreal-time  prototype, 
and  then  to  transition  that  system  in  Phase  2  into 
an  avionics-consistent  processing  architecture 
for  the  real-time  demonstration  and  evaluation. 
There  would  be  no  absolute  requirement  to  use 
flight-worthy,  military  qualified  processors  in 
Phase  2  due  to  availability  of  some  of  the  newer 
hardware  and  expense;  the  goal  is  consistency 
in  architecture  and  performance. 

The  Pilot's  Associate  concept,  Figpire  1, 
somewhat  conceptualizes  another  evolution  of 


The  Pilot's  Associate  program  is  a  joint  Defense 
Advanced  Research  ^ojects  Agen^ 
(DARPAyU.S.  Air  Force  program  which  began 
in  February  1986  as  an  application 
demonstration  for  the  DAj^A  Strategic 
Computing  program.  The  program  was 
organized  into  two  phases  with  two 
demonstrations  in  Phase  1  (referred  to  as 
Demonstration  2  and  Demonstration  3),  and  a 
final  man-in-the-loop  demonstration  and 
evaluation,  Demonstratimi  4,  in  Phase  2.  The 
original  program  philosophy  was  to  explore  the 
potential  of  artifi^l  intelligence  to  improve  the 
decision-making  ability  of  the  pilot  of  an 
advanced,  single-seat  flgbter.  As  an  application 
of  Strategic  Computing,  there  was  no  limitation 


program  philosophy  during  the  first  phase  of  the 
program.  The  original  vision  of  artificial 
intelligence,  and  expert  or  knowledge-base 
systems  in  particular,  has  proven  too  narrow 
with  respect  to  the  desired  behaviour  of  the  Pilot's 
Associate.  That  is,  rather  than  exploring  the 
application  of  a  technology,  artificial 
intelligence  in  this  case,  the  prt^am  has 
evolved  into  the  application  of  whatever 
techniques  apply  to  effect  the  desired  intelligent 
behaviour  ascribed  to  Pilot's  Associate.  This 
new  philosophy  is  perhaps  best  described  as  an 
"intelligent  systems”  approach  which  makes  no 
assumptions  about  underlying  technologies. 
This  may  appear  to  be  a  subtle,  semantic 
argument,  but  it  truly  reflects  a  mrgor  evolution 
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in  program  philosophy  to  be  requirements  driven 
rather  than  technology  driven. 

A  more  complete  description  of  the  original  goals 
and  program  philosophy,  and  a  description  of  the 
five  major  functional  components  can  be  found 
in  [1,  2,  3].  Much  of  the  following  description  of 
the  early  Phase  1  work  through  Demonstration 
2X  is  drawn  from  [4], 

There  have  been  two  unique  approaches  to  system 
development  explored  independently  by  two 


contractor  teams  in  Phase  1 .  An  article  on  the 
Lockheed  Aeronautical  Systems  Corporation 
program  will  appear  in  the  June  1991  issue  of 
TRRlg  Expert.  The  remainder  of  this  paper  will 
provide  some  insight  into  the  other  effort  as 
performed  by  the  McDonnell  Aircraft  Company 
team.  The  reader  is  advised  that  the  ensuing 
technical  discussion  of  the  program  is  written 
from  the  perspective  of  the  McDonnell  team  effort 
and  is  intended  to  apply  solely  to  that  effort. 


€NHANC£D 
^  SITUATIONAL 
>  AWARENESS 


BETTER 

DECISIONS 


Figure  1. 

Pilot's  Associate  Concept 


3.  DEMONSTRATION  2 

The  McDonnell  team  approach  to  a  Pilot's 
Associate  system  focused  on  air-to-ground 
functionality.  The  original  system  design  was 
consistent  with  the  “technology  pull”  objective  of 
Strategic  Computing.  The  design  was  oriented 
towards  a  hypothetical,  massively-parallel, 
shared-memory  processor  architecture  as  the 
most  appropriate  configuration  for  a  real-time 
Pilot's  ^sociate  at  the  conclusion  of  Phase  2. 
This  design  decision  was  founded  on  studies 
which  concluded  that  70-90%  of  rule-based 
system  operations  were  pattern-matching 
operations.  This  design  philosophy  resulted  in  a 
homogeneous,  fine-grained  rule  structure  used  to 


implement  every  aspect  of  the  system,  including 
some  procedural  code. 

A  miyor  part  of  the  design  included  the  concept  of 
a  single,  global  blackboard  facilitated  by  shared- 
memory.  Since  a  requirement  for  the  software 
implementation  called  for  distributed,  symbolic 
processors  (six  Explorers  and  a  microVax),  a 
technique  was  devised  to  allow  the  host  language, 
ART^  to  nin  synchronously  on  each  machine. 
To  simulate  the  global  bladcboard,  working 
memory  changes  had  to  be  pr<^agated  throughout 
all  of  the  subsystems.  The  flight  simulation 
would  execute  one  “tick'',  then  the  subsystems 
would  execute  their  agenda  and  propagate 


1  Automated  Reasoning  Tool,  Inference  Corporation 


16-3 


changes  to  the  other  subsystems,  then  the  cycle 
would  repeat.  In  addition  to  the  overhead  of  this 
process,  advanced  features  of  ART,  sudi  as 
schemas  and  viewpoints,  were  exploited  at 
further  expense  of  processing  time. 

Work  in  this  early  development  effort  was 
centered  on  detailed  design  and  specifications, 
with  small  prototypes  dedicated  to 
communications  and  control  architecture.  The 
first,  major  functional  build  and  integration 
occurred  as  the  prototype  for  Demonstration  2, 
and,  for  the  first  time,  severe  performance 
problems  surfaced.  In  June  1988,  Demonstration 
2  occurred;  however,  only  one  of  six  original 
mission  segments  was  supported  by  fully 
integrated  software.  The  inability  to  complete  a 
full  demonstration  was  primarily  caused  by  a 
run  time  of  approximately  120:1  —  1  minute  of 
simulation  time  resulted  in  two  hours  of 
processing  time.  The  result  of  this  extremely 
slow  run  time  was  an  almost  impossible 
development  and  testing  environment. 

3.1,  SYSTEM  PERFORMANCE  ANALYSIS. 

Following  Demonstration  2,  a  serious,  in-depth 
analysis  of  system  performance  was 
undertaken.  The  approach  used  in  the  system 
analysis  was  to  perform  both  timing  and  impact 
analyses.  The  timing  analysis  provided 
quantitative  data  on  the  Demonstration  2  system 
performance.  The  impact  analysis  identified 
key  features  of  the  Demonstration  2  system 
design  and  implementation  that  influenced 
performance.  From  this  analysis,  design 
change  recommendations  were  generated.  A 
key  factor  in  generating  the  design  changes  was 
the  recognition  that  the  goals  of  the  program  were 
changing  from  those  of  Demonstration  2,  as 
described  above.  Although  McDonnell  was  not  to 
immediately  address  the  redirection  to  a  near- 
term  aircraft,  the  knowledge  of  the  changes  did 
provide  this  early  influence.  Also  influencing 
the  design  recommendations  was  the  work  of  the 
real-time  investigation  effort,  which  had  been 
directed  to  address  near  term,  real-time 
implementation  approaches  for  Pilot's  Associate, 
discussed  in  a  later  section  of  this  paper. 

The  result  of  the  timing  and  impact  analysis 
confirmed  the  almost  painfully  obvious 
conclusion:  an  approach  towards  large-scale 
parallelism  forced  expensive  compromises  in 
knowledge  structures  and  near-term 
implementation.  The  following  points  further 
detail  the  poor  run-time  performance  of  the 
Demonstration  2  sjrstem: 


1.  The  strong  commitment  to  large  scale 
parallelism  was  the  primary  factor  in  the 
decision  to  have  a  synchronous  Pilot's 
Associate/Simulation  and  module  operation, 
and  in  the  adoption  of  the  fine-grained  rule 
structure.  The  choice  of  a  ^chronous 
architecture  led  to  additional  buffering  and 
process  waiting.  This  problem  was 
compounded  because  the  implementation  of  the 
synchronous  architecture  was  not  streamlined 
for  run-time  efficiency.  Module 
^chronization  was  implemented  by  splitting 
the  right-hand  side  of  the  ART  function  which 
lead  to  additional  communications  and 
buffering  overhead. 

2.  The  modeling  of  a  massively-parallel 
environment  required  the  use  of  a  fine¬ 
grained  rule  structure  leading  to  an  increased 
rule  base  size,  increased  pattern  and  join  net 
size,  and  increased  redundancy  in  rules 
because  of  the  restriction  to  have  only  one  right- 
hand  side  action.  In  addition,  sequential 
dependencies  were  represented  explicitly  in  the 
left-hand  sides  of  rules  by  control  tokens. 

3.  The  natural  functional  partitioning 
imposed  by  subsystem  boundaries  was 
maintained  with  some  effort.  The  functional 
partitioning  could  have  been  streamlined  for 
the  particular  hardware  configuration.  The 
partitioning  led  to  processor  overloads  and  an 
inefficient,  multi-processing  environment. 

4.  Hypothetical  planning  was  implemented 
using  the  ART  viewpoint  construct  which 
added  overhead  to  schema  processing 
extending  the  step  time  and  increasing  the 
memory  requirements.  The  general  approach 
to  using  ART  data  structures  also  contributed  to 
increased  memory  and  step  time.  These  data 
structures  included  the  exclusive  use  of 
schemas,  viewpoints,  and  hierarchical  data 
structures. 

A  revised  system  architecture  was  recommended 
as  a  result  of  this  analysis.  The  new 
architecture  abandoned  fine-grained  rules  in 
favor  of  small-scale  parallelism,  coarse¬ 
grained  rule  structure,  and  control  implemented 
by  a  priority  structure  and  agenda  management. 
For  system  implementation  the 
recommendations  included:  eliminate  the  use  of 
viewpoints;  reduce  the  use  of  schema-based, 
hierarchical  data  structures;  use  facts  and  LISP 
structures  in  addition  to  schema;  and  make 
more  use  of  procedural  code.  Mo<lif3ring 
functional  partitioning  to  reduce 
communications  and  using  asynchronous 
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communications  between  Pilot's  Associate  and 
the  flight  simulation  were  also  recommended. 

a^DEMQMSmTlQWZX 

Demonstration  2X,  was  scheduled  for  February 
1989  to  address  the  rebuilding  and  recovery  of  the 
Phase  1  design  and  implementation. 
Demonstration  requirements  included 
successful  completion  of  the  first  three  of  the  six 
Demonstration  2  air-to-ground  mission 
segments  with  a  performance  goal  of  10:1  real¬ 
time. 

The  process  involved  in  Demonstration  2X 
development  required  re-building  all  of  the 
communications  and  control  structure,  and 
recoding  a  major  portion  of  the  individual 
subsystems  during  only  five  months  of 
development  time.  The  revised  architecture, 
with  concentration  in  the  functional  areas  of 
Mission  Planner,  Pilot- Vehicle  Interface,  and 
Situation  Assessment,  would  be  the  emphasis  of 
development  for  this  demonstration. 

The  Demonstration  2X  Pilot's  Associate  was 
hosted  in  both  a  laboratoiyr  simulation  on  a 
graphics  workstation,  and  in  a  full  cockpit 
within  a  40-foot  dome  equipped  with  a  high- 
fidelity,  out-the-window  visual  system.  The 
advanced  simulation  capability  provided  for 
qualitative  evaluation  of  Pilot's  Associate 
capabilities  in  a  realistic  combat  environment 
as  early  as  possible  in  the  development  process. 
Initial  prototype  software  development,  testing, 
and  debugging  took  place  in  the  laboratoiy. 

Then  the  software  was  ported  to  equivalent 
hardware  in  the  dome  for  more  complete  testing 
and  evaluation  prior  to  the  next  prototype  cycle. 

Mission  Scenario  The  Demonstration  2X 
mission  was  a  single-ship,  air-to-ground 
battlefield  air  interdiction  mission  with  a  mobile 
column  of  tanks  as  the  primaiyr  target.  The 
mission  events  included  forward  edge  of  the 
battle  area  (FEBA)  penetration,  ingress  to  the 
target  area  at  low  level  and  high  speed,  target 
attack,  and  low  level  egress  through  threat 
defenses.  The  Pilot's  Associate  aircraft  was 
modeled  using  F-15  capabilities  with  advanced 
air-to-ground  systems. 

The  mission  begins  just  prior  to  crossing  the 
FEBA  when  the  Pilot's  A^ciate  performs  the 
“fence  check”  to  configure  weapons  and  sensors 
for  the  mission.  Nominal  altitude  for  the 
mission  is  200  feet  above  ground  level  with  an 
airspeed  of 450  knots.  Soon  after  FEBA 
penetration,  an  unknown  surface-to-air  missile 


(SAM)  site  search  radar  “pops-up”  which  impacts 
the  planned  route  but  at  sufficient  distance  to 
allow  Pilot's  Associate  to  create  a  new  route  to 
avoid  the  new  threat.  After  successfully  avoiding 
the  SAM  threat,  and  guided  1^  the  Pilot's 
Associate  mission  plan  to  minimize  additional 
SAM  exposure,  a  target  redirect  message  is 
received  over  data  link  to  attack  an  alternate 
target  location  of  tanks.  Pilot's  Associate  creates 
a  low-altitude,  terrain-following  route  plan  to  the 
new  target  The  plan  minimizes  exposure  to  the 
known  missile  sites  by  exploiting  terrain  to 
mask  the  Pilot's  Associate  aircraft.  As  the  pilot 
closes  in  on  the  target,  the  Pilot's  Associate 
configures  sensors  and  displays  consistent  with 
the  requirements  for  target  acquisition  by 
selecting:  the  High  Resolution  Map  mode  of  the 
air-to-ground  radar  at  long  range;  the  Forward 
Looking  Infrared  Receiver  at  short  range;  and 
for  target  attack  using  the  sensor  on-board  the 
Maverick  missile.  Immediately  following 
weapons  launch,  another  unknown  SAM  appears 
within  a  threatening  radius  of  the  aircraft. 

Pilot’s  Associate  develops  a  short-term  route  plan 
to  quickly  get  the  aircraft  out  of  the  area  of  SAM 
exposure.  While  still  within  the  lethal  radius  of 
the  SAM  site,  the  pilot  exploits  the  large,  heads- 
down  display  of  the  terrain  superimposed  with 
the  SAM  range  and  line-of-sight  information  to 
help  maintain  an  awareness  of  possible  exposure 
and  particularly  dangerous  areas.  Pilot’s 
Associate  highlights  the  most  critical  SAM  site 
and  includes  a  dynamic,  “within  parameters” 
shot  indication  to  advise  the  pilot  of  critical 
exposure.  After  the  threatening  SAM  is 
successfully  evaded,  Pilot's  Associate  safely 
guides  mission  egress  through  areas  of  high 
threat  defenses. 

Technical  Oyervievt.  Using  the  results  and 
recommendations  from  the  Demonstration  2 
system  performance  analysis,  the  entire 
approach  to  air-to-ground  functionality  took  on  a 
new  perspective.  The  rule  structure  was 
completely  changed  into  a  knowledge  source 
format  consistent  with  a  design  for  real-time 
processing.  The  knowledge  sources  were  written 
in  a  generic  form  and  precompiled  into  ART 
rules  for  execution.  The  system  used  a 
distributed  blackboard  which  consisted  of  LISP 
variables  and  ART  working  memory,  as  shown 
in  Figure  2.  To  achieve  improved  run-time 
performance,  the  use  of  ART  was  tailored,  and 
inefficient  data  structures  (schema  and 
viewpoints)  were  avoided.  The  subsystems 
updated  the  global  blackboard  a83mchronou8ly 
and  communications  between  local  blackboards 
were  expressed  as  system  goals.  Global  system 
goals  were  established  by  problem  events,  such  as 
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receiving  a  mission  target  redirection,  or  by 
inference  of  pilot  goals  from  cockpit  actions. 

The  ^stem  goals  were  managed  by  a  System 
Executive  (SE),  an  additional  sub^stem  in  this 
Pilot's  Associate  implementation.  SE  contained 
knowledge  sources  to  recognize  system  problem 
events,  established  goals  to  deal  with  the  events, 
and  monitored  for  their  success  or  failure. 

The  full-cockpit,  high-fidelity  demonstration  of 
the  Demonstration  2X  siystem  executed  in  real¬ 
time,  significantly  exceeding  the  performance 
goal.  This  system  performance  was  attributed  to 
factors  which  lessen  the  validity  of  the  claim  to 
real-time  execution.  The  Demonstration  2X 
Pilot's  Associate  system  was  a  functional 
skeleton;  the  breadth  and  depth  necessary  for 


system  robustness  was  severely  lacking  in 
many  areas.  A  miyor  influence  on  performance 
was  the  method  of  determining  the  search  space 
for  route  planning  purposes.  The  danger  maps 
used  by  the  route  planner  were  computed  off-line 
prior  to  the  simulation;  a  process  which  required 
several  minutes  to  complete.  The  danger  map 
algorithm  was  analogous  to  the  cost  matrix 
computation  in  the  dynamic  programming  route 
planner.  If  on-line,  these  computations  would 
have  been  a  significant  performance  drain.  A 
more  difficult  threat  environment  could  also 
cause  the  A*  route  planner  responsiveness  to 
degrade  significantly  Therefore,  the  only 
credible  claim  is  that  the  performance 
improvement  from  the  Demonstration  2  system 
was  impressive. 


Figure  2. 

Demonstration  2X  Subsystem  Internal  Architecture 


Pilot-Vehicle  Interface  (PVD  experienced  a 
mqjor  redesign  during  the  Demonstration  2X 
development  period.  Elements  included  in  the 
PVI  design  were  display  management,  a  pilot 
awareness  model,  pilot  intent,  and  a  task 
scheduling  and  workload  model.  Most  effort 
concentrated  on  the  display  management 
function  which  used  scripts  to  establish  display 
priorities.  Although  a  full  complement  of  design 
elements  were  included  in  the  Demonstration  2X 
PVI  design,  most  functions  were  implemented 
only  in  skeletal  form. 

Situation  Asseasment  fSA)  consisted  of  two 
support  functions  as  resources  to  perform 
assessments  for  other  Pilot's  Associate 
subsystems.  The  first  support  resource,  a  danger 
map  algorithm,  defined  the  search  space  for  the 
route  planning  algorithm  of  the  Mission 


Planner.  The  danger  map,  a  2-dimensional 
map  fixed  at  a  200  foot  altitude,  was  a  composite  of 
known  threat  lethality  and  intervisibility 
information  which  provided  a  measure  of 
“danger”  associated  with  each  point  on  the  map. 
Because  the  danger  map  was  computer  off-line 
for  Demonstration  2X,  SA  simply  maintained  an 
interface  to  the  danger  map.  The  other  support 
resource,  a  spatial  data  base,  quickly  computed 
the  intersection  of  objects,  such  as  route  paths  and 
threat  regions,  to  flag  threatening  segments  of 
the  route  plan  when  replanning  was  required. 

SA  also  added  value  to  sensor  data  on  threats  to 
the  Pilot's  Associate  aircraft  by  inferring  threat 
status,  such  as  search  or  track;  threat  potential, 
such  as  time  to  intercept  envelope  and  earliest 
shot  indication;  and  threat  priority.  SA 
considered  only  ground  threats  in  the 
assessments. 
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Mission  Planner  and  Tactics  Planner  (MTP) 
functions  were  combined,  although,  a  response 
decision  to  the  pop-up  SAM  event  was  the  only 
tactics  planning  function  implemented.  This 
decision  amounted  to  a  choice  between  a  long¬ 
term  avoid  response  and  a  short-term  evade 
response,  and  was  driven  primarily  by  distance 
from  the  threatening  SAM  site.  The  choice  to 
avoid  or  evade  the  new  threat  then  drove  mission 
planning  activities  for  countering  the  threat 

To  develop  route  plans,  the  mission  planner 
subfunction  used  a  two-level.  A*  heuristic  search 
over  the  danger  map.  First,  a  waypoint  planner 
performed  a  coarse  search  of  the  the  danger  map 
search  space  and  selected  appropriate  waypoints 
for  the  route  plan.  This  planner  also  selected 
points  for  the  high  resolution  map  acquisition  of 
the  target  and  the  initial  point  for  target  attack. 

A  fine-grained  planner  then  developed  routes 
between  waypoints.  As  a  post-planning  process, 
a  resource  planner  allocated  fuel  and  aircraft 
speed  to  the  route  plan  to  maintain  a  fixed  time- 
on-target.  As  the  aircraft  is  flying  the  route  plan, 
a  plan  conformance  monitor  evaluated  fuel 
levels,  speed  of  flight,  and  the  path  corridor 
definitions  to  detect  violations  with  potentially 
adverse  mission  impact.  The  framework  for 
resource-  or  mission-level  replanning  existed  to 
remediate  violations  which  affected  mission 
effectiveness  or  survivability,  however,  this 
functionality  was  not  implemented  by  the 
demonstration. 

In  response  to  the  SAM  avoid  or  evade 
recommendations  developed  by  the  tactics 
planner  subfunction,  the  mission  planner  either 
planned  a  mission  level  response  or  a  tactical 
level  response,  respectively.  The  mission  level 
response  replanned  ingress,  attack  and  egress 
portions  of  the  mission  as  required  using  the 
waypoint  planner,  route  planner,  and  resource 
planner.  The  tactical  level  response  replanned 
only  the  affected  seg^ments  of  the  mission  plan, 
as  identified  by  Situation  Assessment,  using  the 
route  planner  and  the  resource  planner. 

The  A*  route  planner  was  implemented  in  LISP, 
with  all  other  code  in  MTP  in  the  previously 
mentioned  knowledge  source  format. 

System  Status  was  practically  nonexistent  at 
Demonstration  2X.  The  only  responsibility 
attributed  to  this  function  was  fuel  monitoring 
and  reporting  of  fuel  status  to  PVI  and  MTP. 


3.3  DEMONSTRATION  3 

A  period  of  development  time  lapsed  between  the 
Pilot’s  Associate  Demonstration  2X  milestone 
and  the  beginning  of  effort  on  the  Phase  1 
redirection  to  apply  Pilot's  Associate  technology 
to  a  current  or  planned  service  aircraft.  The 
aircraft  platform  chosen  for  the  air-to-ground 
effort  was  an  advanced  Navy  F/A-18.  Because  of 
the  time  lapse  of  development  effort  and  the 
extensive  analysis  accomplished  on  the 
Demonstration  2  system.  Demonstration  3  was 
not  scheduled  until  Oct  1990. 

The  Demonstration  3  Pilot's  Associate  used  both 
the  laboratory  simulation  on  a  graphics 
workstation,  and  the  full  cockpit  with  in  a  40-foot 
dome  equipped  with  a  high-fidelity,  out-the- 
window  visual  system  as  in  Demonstration  2X. 
Both  the  laboratory  simulation  and  the  actual 
dome  used  have  changed,  but  the  dual-site 
approach  to  cyclic  software  development,  testing, 
and  evaluation  proceeded  as  before.  The  Pilot's 
Associate  system  development  continued  the  use 
of  LISP,  the  knowledge  source  format,  and 
symbolic  processors  due  to  the  flexibilities  of  the 
language  and  the  efficient  development 
environment  provided.  Some  of  the  support 
functions  were  coded  in  other  programming 
languages  for  run-time  efficiency. 

Mission  Scenario.  The  Demonstration  3 
scenario  was  considerably  more  flexible  than 
that  of  Demonstration  2X.  Advances  in  both  the 
laboratory  and  flight  simulation  allowed  rapid 
changes  in  the  environments  to  test  Pilot's 
Associate  capabilities  under  varying  conditions. 
Two  basic  air-to-ground  missions  were  defined 
for  Demonstration  3:  a  two-ship  Day/Night 
Strike  mission,  and  a  two-ship  Battlefield  Air 
Interdiction  mission.  The  visible  difference 
between  mission  types  was  either  a  tactical  (e.g. 
a  marshalling  tank  column)  or  a  strategic  target 
(e.g.  fuels  storage  area).  Other  selectable 
mission  variables  included  threats,  aircraft 
stores,  and  weather.  Demonstration  3 
concentrated  on  the  target  acquisition  and  attack 
phase  of  the  chosen  mission.  Mission  events 
included  air  threats,  SAM  threats  and  launches, 
sensor  use  and  failures,  target  identification 
and  attack,  and  two-ship  rejoin. 

Technical  Overview.  Progress  toward 
Demonstration  3  occurred  rapidly.  Again,  with 
the  luxury  of  the  time  lapse  and  the  extensive 
analysis  of  system  parameters  required  to 
achieve  real-time  operation,  the  development 
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efTort  refined  the  goals  and  approach  to 
incorporate  new  ideas. 

The  basic  structure  of  the  blackboard  architecture 
remained  from  the  Demonstration  2X  ^stem 
with  several  enhancements  implemented  to 
make  the  blackboard  more  useful  for  the 
Demonstration  3  system.  The  blackboard 
enhancements  included  modification  of  the 
knowledge  source  syntax  to  allow  specification 
for  urgency  and  importance,  and  modification  of 
the  ART  agenda  to  allow  heuristic  scheduling. 
These  important  features  allowed  for  real-time 
control  and  were  essential  aspects  in  Pilot's 
Associate  realization  of  the  Demonstration  3 
run-time  goals. 

Along  with  the  real-time  distributed-blackboard 
architecture,  the  primary  component  of  the 
system  software  framework  was  the  task 
network  concept.  The  task  network  is  used  to 
model  Pilot's  Associate  and  pilot  activity,  and 
the  activity  of  external  agents.  This  structure 
allowed  the  PVI  to  reason  about  pilot  actions  and 
the  pilot/Pilot's  Associate  interactions.  The 
network  also  provided  a  mechanism  for 
communicating  and  responding  to  exceptional 
circumstances  that  may  arise  in  the  dynamic, 
tactical,  combat  environment.  Therefore,  the 
network  provided  a  platform  for  integrating  the 
monitoring  activities  of  the  assessors  with  the 
planning  activities,  and  the  cockpit 
management  provided  by  the  pilot-vehicle 


interface.  Also,  this  framework  provided  a 
consistent  software  foundation  for  integrating 
the  varied  domain  knowledge. 

As  models  of  system  activity,  task  network  nodes 
could  be  further  decomposed  into  more  specific 
tasks  or  represented  as  primitive  tasks. 

Primitive  tasks  referred  to  either  Pilot’s 
Associate  or  pilot  actions.  Domain  knowledge, 
associated  with  a  task,  included  methods  for 
deciding  when  the  task  is  appropriate,  for 
implementing  the  task,  for  monitoring  of  task 
execution  and  dependencies,  for  handling 
exceptions,  and  generating  scheduling 
parameters  such  as  importance  and  urgency  for 
a  specific  task.  Pilot's  Associate  plans  were 
presented  as  partially  ordered  graphs  of  tasks. 
Partial  ordering  in  this  context  referred  to  the 
ability  to  represent  concurrent  tasks  with  no 
single  ordering  constraint.  The  ability  to 
represent  a  task  as  a  set  of  less  abstract  tasks  led 
to  a  hierarchical  representation.  This  task 
hierarchy  allowed  exception  handling  (control 
knowledge)  to  be  applied  locally  or  by  higher  task 
abstraction  level.  Exceptions  were  events  — 
determined  from  the  monitoring  of  aircraft 
resources,  pilot  actions,  the  external 
environment,  and  the  operation  of  other  Pilot's 
Associate  tasks  —  that  could  significantly  effect 
current  or  planned  tasks.  Exceptions  and 
exception  handling  provided  the  method  to  adapt 
the  task  network  to  the  dynamic  environment. 


Figure  3. 

Demonstration  3  Generic  Task  and  Plan  Representation 

Pilot's  Associate  task  scheduling  and  execution  that  integrated  the  Pilot's  Associate  blackboard 

were  performed  fay  an  underlying  software  layer  architecture  with  a  real-time  operating  system. 
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The  task  network  and  the  blackboard 
architecture  worked  in  concert  to  assure  timely 
execution  of  primitive  tasks.  The  task  network 
communicated  with  the  blackboard  by  asserting 
tokens  when  tasks  were  activated.  These  tokens 
triggered  knowledge  sources  which  performed 
the  following:  monitoring  for  task  completion  or 
exceptions,  calculating  pilot  information 
requirements,  and  performing  actions  which 
have  been  authorized  for  automation.  This  task 
network/blackboard  interface  was  a 
fundamental  component  of  the  Demonstration  3 
software  architecture. 

The  Demonstration  3  Pilot's  Associate  still 
lacked  the  functionality  depth  required  for  a 
fully  robust  system,  and  any  claims  of  real-time 
execution  must  continue  to  be  evaluated  on  this 
basis.  However,  the  real-time  architecture 
developed  for  this  prototype  established  a  strong 
framework  for  further  functional  integration  in 
Phase  2  development. 

Pilot-Vehicle  Interface  (PVD  functional 
objectives  —  to  support  pilot  decision-making,  to 
present  information  intelligently,  and  to  assure 
alignment  of  Pilot's  Associate  and  pilot  goals  — 
continued  to  be  the  driving  force  for  the  design. 
This  design,  however,  changed  from  the 
Demonstration  2X  implementation  and  relied  on 
the  task  network  software  architecture.  The  PVI 
design  linked  active  tasks  from  the  task  network 
to  pilot  information  requirements  (PlRs)  by  the 
pilot  information  requirements  generator.  This 
function  was  derived  from  a  mission 
decomposition  in  which  pilots  detailed  their 
mission  activity  and  the  information  required  to 
perform  this  activity.  The  pilot  information 
requirements  were  used  as  input  into  the  cockpit 
display  manager  which  chose,  scheduled,  and 
then  executed  the  display  agenda.  The  cockpit 
display  msuiager  selected  a  list  of  candidate 
display  elements  based  on  the  PIRs,  mission 
context,  and  the  pilot  workload  assessment 
function.  The  displays  were  scheduled  by 
priority  and  pilot  explicit  selection.  If  the  PIRs 
were  satisfied  by  a  current  display,  they  were 
marked  as  such.  If  the  display  of  choice  was 
occupied  by  a  higher  priority  requirement,  an 
alternate  choice  was  made  until  all  PIRs  were 
satisfied  by  display  scheduling.  The  PVI  then 
made  use  of  a  pilot  task  and  goal  monitor  which 
assessed  pilot  actions  and  active  tasks  to 
determine  if  the  active  tasks  were  appropriate,  or 
if  exceptions  to  the  current  planning 
assumptions  had  occurred.  The  design  also 
included  pilot  awareness  assessor  and  error 
monitor  functions,  but  these  functions  were  not 
implemented  in  the  demonstration  system. 


Situation  Assessment  (SA)  retained  the 
functionality  of  Demonstration  2X,  but  changed 
implementation  to  reflect  real-time  analysis 
efforts  and  interactions  with  the  task  network. 
SA  monitored  for  tactical  objects,  such  as  threats, 
targets,  support  forces,  and  environmental 
factors  which  had  possible  impact  on  the  current, 
active  plan  in  the  task  network.  Because  of  the 
uncertain,  current  state  and  the  unpredictable, 
future  state  of  a  dynamic  environment,  certain 
assumptions  on  the  current  state  of  the  world 
were  made  for  planning  purposes.  If  those 
assumptions  were  violated  by  tactical  object 
changes,  SA  generated  notice,  via  exceptions, 
that  the  planning  assumptions  were  no  longer 
valid  and  alternate  planning  must  be 
considered.  SA  also  coordinated  information 
requests  and  usage  constraints  and  formulated  a 
sensor  request  plan  for  a  sensor  manager 
external  to  Pilot's  Associate.  SA  continued  to 
support  functional  interfaces  to  the  spatial  data 
base  and  danger  map.  However,  unlike  the 
Demonstration  2X  system,  the  Demonstration  3 
system  updated  the  danger  map  on-line.  This 
made  the  subsystem  a  true  assessor,  able  to: 
assess  changes  in  the  outside  environment  and 
how  they  relate  to  other  Pilot's  Associate  activity; 
update  the  Pilot's  Associate  model  of  the 
environment  to  reflect  changes;  and  produce  an 
accurate,  timely  danger  map  for  the  pilot  and 
mission  planner. 

Mission  Planner/Tactical  Planner  (MTP)  had 
one  Demonstration  3  functional  goal:  to 
represent  a  robust  mission  and  target  attack 
plan.  To  accomplish  this  goal,  MTP  continually 
monitored  the  mission  and  target  attack  plan  for 
effectiveness  with  respect  to  changes  in  the 
aircraft  capabilities  and  environment.  Since  the 
Demonstration  3  mission  concentrated 
specifically  on  the  target  attack  segment  of  an 
air-to-ground  mission,  replan  only  considered 
the  target  attack  segment  and  a  global  mission 
replan  was  not  required. 

MTP  design  included  three  major  functions:  a 
plan  monitor,  plan  execution  function,  and  a 
plan  generator.  The  plan  monitor  architecture 
derived  its  structure  from  the  task  network.  The 
task  network  allowed  detection  of  assumption 
violations  associated  with  the  current  planning, 
and  prediction  of  the  impact  of  the  assumption 
violations  on  the  current  plan  steps.  Although  the 
detection  method  for  planning  violations  was 
altered,  the  plan  parameter  monitor  software 
remained  mostly  unchanged.  The  plan  executor 
architecture,  enhanced  by  task  network  support, 
continued  to  use  the  existing  route  plan  execution 
software.  The  plan  generator  function  was 
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supported  by  the  task  network  architecture  and 
consisted  of  four  controlling  functions:  a 
strategy  selection  function,  route  planner,  target 
attack  planner,  and  countermeasure  planner. 
The  strategy  selection  function  was  performed 
using  planning  scripts  and  the  task  network 
planning  structure.  The  planning  scripts  used 
declarative  representations  of  the  subgoals  that 
must  be  achieved  to  satisfy  the  system  goal  which 
initiated  the  planning  process.  The  task 
network  provided  an  alternate  representation  of 
planning  strategies  which  allowed  a  more 
general,  but  limited  number  of  strategies  to  be 
considered  for  planning.  The  new  target  attack 
planner  consisted  of  attack  templates  which 
defined  stereotypical  delivery  representations 
and  cooperative  tactics.  Each  template  was 
adapted  to  the  current  mission  situation  as 
planning  occurred.  This  approach  defined  a 
limited  target  attack  modification  search  space 
and  allowed  rapid  comparisons  for  selecting 
alternative  plans  due  to  situation  contingencies. 
The  countermeasure  planner  identified  threat 
suppression  plans  which  mainly  consisted  of 
executing  the  appropriate  maneuvers  to  establish 
optimal  geometjy  with  respect  to  the  threat.  Each 
threat  suppression  plan  was  represented  as  a 
flight  plan  consisting  of  a  set  of  maneuver 
segments  with  subtasks  inserted  at  appropriate 
places  in  the  plan  indicating  where  to  apply 
countermeasures,  such  as  jammers  and 
deployment  of  expendables.  Plan  selection 
dependence  factors  included  threat  information, 
timing  constraints,  location  to  target  area, 
environmental  constraints  provided  by  Situation 
Assessment,  and  aircraft  constraints  provided 
by  Systems  Status. 

System  Status  (SS)  increased  tremendously  in 
scope  from  Demonstration  2X,  but  remained  a 
skeleton  of  what  was  envisioned  in  the  original 
plans.  The  role  of  SS  was  to  provide  continual 
assessment  of  the  aircraft's  capability,  and  to 
assist  in  remediation  planning  to  remedy 
system  failures  and  maintain  aircraft 
capability.  The  implementation  of  this  role  was 
somewhat  less  grand,  consisting  of  rather 
simple  capability  models  of  aircraft  resources: 
navigation  system,  fuel,  flight  dynamics, 
sensors,  weapons,  signature,  and 
countermeasures.  Since  mission  and  tactical 
plans  required  use  of  specific  aircraft  resources, 
SS  maintained  the  availability  status  of  each 
resource.  SS  also  had  parameters  defined  for 
each  model  to  determine  if  the  resource  was 
viable  or  failed.  The  failed  status  was 


communicated  to  the  system  through  plan 
assumption  violations,  via  exceptions,  similar  to 
Situation  Assessment. 

System  Executive  (SE)  played  an  important  role 
in  the  system  design  for  this  effort.  The 
functional  requirements  for  SE  were  defined  as 
follows:  coordinate  Pilot's  Associate  problem 
solving;  manage  system- wide  timeliness; 
maintain  consistency  between  pilot  and  Pilot's 
Associate  problem  solving  goals;  and  support 
run-time  resource  management.  These 
requirements  were  blended  in  an  elegant  design 
in  which  SE  was  viewed  as  a  functional 
requirement,  not  an  added  component.  The 
design  involved  both  a  centralized  component 
(central  executive)  and  a  module  component 
(embodied  by  the  task  network).  The  central 
executive  was  the  effort  covered  solely  under  SE 
efforts. 

The  System  Executive  maintained  a  model  of 
system  activity.  Whenever  exceptions  were 
generated  by  the  subsystems,  the  task  network 
hierarchy  allowed  local  exception  handling,  or, 
depending  on  the  exception,  propagation  of  the 
exception  to  a  higher  abstraction  level.  If  the 
exception  was  propagated  to  the  highest  level  in 
the  task  network,  this  constituted  violation  of  a 
system  level  goal  and  SE  central  control 
assumed  responsibility  for  system  response  to 
account  for  the  exception.  These  response  plans 
included  subsystem  tasks  to  realign  the  Pilot's 
Associate  goals  with  the  current  state.  The  tasks 
contained  subsystem  parameters  and  were  SE's 
primary  means  for  affecting  work  in  progress  in 
the  subsystems.  These  parameters  included 
deadlines,  solution  granularity  (completeness), 
importance,  status  reporting  rate,  and 
assessment  focus.  SE  modified  a  parameter, 
such  as  deadline  or  importance,  in  order  to  affect 
the  solution  associated  with  a  task.  Problem 
solving  goals  and  strategies,  response  plans, 
and  subsystem  parameters  and  status  were  all 
posted  and  coordinated  on  the  blackboard.  All 
plan  coordination  knowledge  and  execution 
were  implemented  as  knowledge  sources.  The 
SE  implementation  considered  all  requirements 
(except  for  the  support  of  system-level  resource 
management  which  should  use  models  of 
subsystem  resources),  and  their  relationships 
and  capabilities,  and  compared  the  models  to 
run-time  resource  states  to  determine  control 
decisions.  Support  of  system-level  resource 
management  was  not  planned  until  after  the 
Demonstration  3  milestone. 
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Figure  4. 

Demonstration  3  System  Executive  Functional  Design 


Real-Time  Investigation  Efforts.  The  real-time 
performance  analysis  of  this  Pilot's  Associate 
approach  consisted  of  the  following  tasks;  an 
assessment  of  the  Pilot's  Associate  real-time 
risks;  an  assessment  of  technologies  to  address 
these  risks;  and  the  selection  of  prototypes  to 
demonstrate  the  selected  technologies. 
Throughout  the  performance  of  these  tasks,  the 
analysis  assumed  that  real-time  performance  in 
a  time-stressed  system  required  three  system 
characteristics;  execution  speed  to  guarantee 
delivery  of  results  within  the  allowed  time; 
system  responsiveness  to  dynamic  task 
demands  by  undertaking  new  tasks  or  shifting 
resources  from  the  current  tasks  to  higher 
priority  ones;  and  graceful  adaptation  when 
workload  exceeds  processing  capacity,  ensuring 
critical  tasks  are  completed.  Speed  of  execution 
could  be  obtained  from  increasing  the  number 
and  power  of  processors  as  well  as  from  efficient 
algorithms.  However,  it  was  reasonable  to 
assume  hardware  and  software  advancements 
would  not  meet  the  raw  speed  required  for  full 
real-time  operation.  Accordingly,  the  approach 
and  conclusions  emphasized  obtaining  system 
responsiveness  and  graceful  adaptation  to 
achieve  intelligent  and  reactive  system 
behavior. 

The  assessment  of  the  Pilot’s  Associate  real-time 
risks  coincided  with  the  Demonstration  2  system 
development  phase  and  identified  bottlenecks  in 
that  design  approach.  These  bottlenecks 
included;  lack  of  responsiveness  to  pilot  or 
external  events;  inability  to  keep  up  with  data 


glut  and  task  overloading;  inability  to  resoond  to 
dynamic  changes  in  workload  due  to  mission 
contingencies;  and  inability  of  Pilot’s  Associate 
modules  to  send  and  receive  messages 
asynchronously.  Once  identified,  these  real¬ 
time  risks  were  then  used  to  guide  the 
development  of  prototype  concepts  for  later 
implementation  in  the  project  demonstrations. 

The  technology  assessment  activity  was 
approached  by  the  following  tasks; 

1.  Investigate  technology  innovations. 

2.  Investigate  alternative  hardware  and 
software  architectures. 

3.  Map  relevant  solution  candidates  to  the 
proposed  architectures. 

4.  Evaluate  solution  candidates  against  the 
technical  criteria. 

5.  Select  the  most  appropriate  hardware  and 
software  model,  and  the  most  significant 
solution  candidates  for  this  model. 

Three  models  of  a  system  architecture  were 
considered  as  candidates  for  Pilot's  Associate. 
Evaluations  of  these  architectures  resulted  in 
selection  of  medium-scale  parallelism  with 
asynchronous  execution  as  the  target 
architecture  —  this  was  consistent  with  the  next 
generation  advanced  aircraft  architectures  or 
projected  upgrades.  Fourteen  software 
innovations  were  identified  to  reduce  the  risk  of 
real-time  operation  by  providing  more  system 
responsiveness.  Each  innovation  was  assessed 
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for  relevance  against  each  of  the  three  hardware 
architecture  models  and  analyzed.  Although 
every  innovation  was  potentially  a  viable 
solution  candidate  for  development,  the  study 
resulted  in  the  selection  of  control  reasoning  and 
focus  of  attention.  Control  reasoning  was 
deflned  as  using  knowledge  about  task 
demands,  time  constraints,  goals,  and  system 
resources  to  select  methods  and  formulate 
schedules.  Focus  of  attention  meant  using 
designs  that  permit  quick  and  efficient  shift  of 
system  attention. 

The  prototype  selection  activity  involved 
comprehensive  analysis  and  matching  of  the 
technical  innovations  suggested  by  the  hardware 
and  software  investigation  task,  to  the  real-time 
risk  areas  indicated  by  the  bottlenecks 
identification  task.  The  prototypes  that  were 
selected  emphasized  the  utility  of  control 
reasoning  to  enhance  timeliness  and  graceful 
adaptation,  and  focus  of  attention  to  provide  real¬ 
time  responsiveness  and  graceful  adaptation 
under  severe  time  stress.  The  choice  of  control 
reasoning  techniques  as  a  focus  for  the 
demonstrations  was  influenced  by  the  desire  to 
move  the  Pilot's  Associate  effort  toward 
implementation  in  the  generation  of  advanced 
aircraft  now  being  designed. 

The  first  real-time  prototype  featured  an  event- 
driven  architecture,  asynchronous  event 
handling,  and  the  use  of  control  reasoning,  focus 
of  attention,  and  an  execution  margin.  The 
focus  of  attention  aspect  was  implemented  by 
multiple  event  channels  for  knowledge  source 
execution  and  a  top-level  control  cycle  designed 
to  process  event  channels  in  order  of  priority. 
Control  reasoning  dynamically  assigned 
importance  and  urgency  ratings  for  each 
knowledge  source;  a  weighted  combination  of 
ratings  based  on  a  dynamic  scheduler  goal,  and 
formulation  of  an  agenda  of  knowledge  sources 
based  on  priorities.  This  demonstration 
provided  features  for  tuning  responsiveness  and 
timeliness.  What  the  demonstration  did  not 
provide  was  a  well-defined  framework  for 
structuring  problem  solving  in  the  Pilot's 
Associate  domain. 

The  second  real-time  prototype  was  to 
demonstrate  timely  and  responsive  performance 
against  a  representative  scenario  and  to  bring 
the  developed  real-time  concepts  and  designs 
closer  to  the  Pilot's  Associate  system  design. 

This  demonstration  featured  three  scenario 
situations,  each  requiring  different  responses  in 
terms  of  system-level  timing  and  activity.  With 
the  focus  of  attention  structure  retained  from  the 


first  prototype,  control  reasoning  was 
implemented  to  select  knowledge  sources  during 
the  top-level  cycle  and  allocate  time  to  the 
knowledge  sources  to  meet  the  deadlines.  The 
theme  of  this  successful  demonstration  was  to 
show  intelligent  reactivity  to  the  demands  of 
varying  events.  Intelligent  reactivity  meant 
that  the  system  had  an  awareness  of  deadlines 
and  the  ability  to  produce  appropriate  results  — 
producing  the  best  response  given  sufficient 
time,  and  producing  an  acceptable  response 
given  inadequate  time. 

The  results  and  concepts  of  the  real-time 
investigations  were  readily  applicable  to  the 
evolving  definition  of  the  Pilot's  Associate 
system.  These  ideas  played  a  vital  role  in  the 
definition  of  the  real-time  distributed  blackboard 
and  also  in  the  definition  of  a  real-time  Pilot's 
Associate. 

4.  CONCLUSION 

The  Pilot's  Associate  program  has  successfully 
completed  the  first  phase  of  development  and 
demonstration  of  an  intelligent  system  in  an 
extremely  complex  and  demanding  domain. 

The  promise  of  operational  utility  of  a  Pilot’s 
Associate  by  improving  the  combat  decision¬ 
making  capability  of  the  pilot  of  an  advanced 
fighter  is  more  evident  as  the  program  moves 
into  the  second  phase  of  development.  As 
development  continues,  the  program  objectives 
shift  from  system  functionality  development  to 
the  real-time  implementation,  demonstration, 
and  experimental  evaluation  of  the  Pilot’s 
Associate.  The  technical  advances,  and  lessons, 
from  the  first  phase  of  development  have 
provided  a  firm  baseline  for  the  real-time 
software  engineering  tasks  ahead. 
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Discussion 

1.  E.GIiatti,  United  States 

How  do  you  maintain  good  documentation  in  rapid 
prototyping  activity? 

Author 

Document  each  prototype  cycle  with  specifications, 
scenarios,  etc.  beforehand  then  a  progress  report  with 
performance  measures  and  lessons  learned  is  prepared  after 
the  prototype.  As  built  design  and  specification  document 
can  be  prepared  at  the  end  of  the  effort.  The  prototype 
reports'  become  an  important  asset  having  captured  the 
process  history. 

2.  G.H.Hunt,  United  Kingdom 

To  achieve  the  best  synergy  between  the  intelligence  of  the 
pilot  and  the  intelligence  imbedded  in  the  Pilot's  Associate 
presumably  requires  a  very  effective  man-machine  interface. 
Are  the  displays  currently  used  in  the  program  adequate  for 
this  purpose? 

Author: 

The  current  displays  effort  is  adequate  only  to  support  the 
test  and  demonstration  in  the  program.  A  concerted  effort 
will  likely  be  needed  towards  intuitive  displays  as  well  as  the 
psychology  of  interaction  between  the  pilot  and  an 
intelligent  machine. 

3. 0.  Bosman,  Netherlands 

Now  having  two  intelligent  systemsfhuman  and  technical), 
both  systems  could  assess  the  performance  and  health  of 
each  other.  The  system  could  warn  the  pilot  for  danger 
potential  in  his  decisions,  of-track  reasoning,  etc.  Do  you 
plan  to  incorporate  such  capability  in  the  Pilot  Associate? 


Author: 

The  foundation  for  PA  monitoring  the  performance  of  the 
pilot  exists  in  the  current  model.  Only  rudimentary  pilot 
workload  or  resource  modelling  is  in  the  current  system,  but 
the  ability  to  use  such  information  is  better  defined.  The 
availability  of  pilot  state  sensors  for  GLOC  or  spatial 
disorientation  or  workload  only  enriches  the  current  ability 
to  effectively  manage  displays  and  workload.  However,  this 
entire  area  of  monitoring  and  control  is  a  very  “pilot- 
sensitive”  issue. 

4.  R.Guiot,  France 

What  about  pilot  creativity? 

Author: 

The  overriding  program  philosophy,  the  pilot  is  in  charge, 
demands  that  the  PA  does  not  obstruct  or  stifle  creativity  on 
the  part  of  the  pilot.  Especially  in  the  area  of  offensive 
tactics,  the  role  of  PA  is  to  provide  support  without  forcing 
him  to  lead  the  computer.  When  lost,  the  computer  must 
“understand”  its  role  to  continue  providing  support  as 
possible  and  to  remain  quiet  and  non-intrusive  until  it  has 
caught  up  with  the  situation. 

5.  G.Bourassa,  Canada 

(a)  Why  are  you  moving  the  software  from  LISP  to  C-H- 
before  going  to  Ada? 

(b)  When  will  the  comparative  evaluation  of  C  and  Ada  be 
complete? 

(c)  Will  the  results  be  published? 

(d)  What  is  the  target  hardware? 

Author: 

(a)  Because  of  a  lack  of  maturity  in  the  distributed  Ada  run 
time  operating  system. 

(b)  At  the  Phase  2  milestone  in  Mar  92. 

(c)  Yes  in  the  final  report  to  be  published  in  DTIC. 

(d)  MIPS  R3000  RISC  processors. 
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DEVELOPMENT  OF  TACTICAL  DECISIO)  AIDS 


W.  G.  Semple 

British  Aerospace  (Military  Aircraft)  Ltd 
Warton  Aerodrome 
Preston  PR4  1AX 
UK 


1  SUMMARY 


.  Increasing  complexity  of  sensors,  weapons  and  counter¬ 
measures  in  combat  aircraft  is  mtroducing  a  requirement  for 
computer  aids  to  the  crew  both  for  data  manipulation  and  in 
more  'intelligent'  tasks  which  have  hitherto  been  considered  the 
province  of  man  rather  than  machine.  A 


^'Gritish  Aerospace  is  pursuing  a  programme  of  Research  and 
Development  of  such  computer  aids  -  Mission  Management 
Aids  -  to  assist  the  pilot  in  the  management  of  combat  missions.  ^ 

'Nks  well  ^  algorithms  of  conventional  *ipe,  t^ng  advantage  of 
the  enormous  and  apparently  continuing  advances  in  process¬ 
ing  har^are,  many  such  akte  will  need  to  exploit  new  concepts 
from  software  engineering  and  artificial  Intelligence. 

We  have  IheM  new  loels  by  which  we  expect  that  we  can  meet 
the  new  requiremenH.  However,  many  of  the  'conventional' 
solutions  are  new  to  wr  experience,  at  least  within  the  stringent 
requirements  of  reayiime  airborne  computing,  and  many  of  the 
new  tools  are  only  partly  developed  or  partly  understood.  This 
is  especially  true  for  some  Tactical  MMAs.  ^ 


would  have  been  unthinkable  when  today's  service  aircraft  were 
being  designed.  These  advances  are  available  for  the  combat 
aircraft  being  designed  now,  and  it  is  clear  that  the  advance  has 
not  yet  stopped;  the  capability  which  the  next  generation  of  air¬ 
borne  design  may  achieve  is  indicated  by  that  of  ground  equip¬ 
ment  available  now. 

We  have  therefore  a  set  of  problems  to  resolve,  and  we  have 
new  and  powerful  hardware  tools  and  rapidly  evolving  software 
tools  and  techniques,  with  which  to  try  to  sol^  them,  wholely  or 
partly.  We  do  not,  however,  have  the  solutions.  There  are 
many  difficulties  and  constraints; 

I)  some  of  the  problems  have  never  been  solved  before,  so 
that  we  have  neither  the  solution,  nor  a  practiced  technique 
for  finding  the  solution; 

ii )  some  of  the  problems  have  been  solved,  or  are  easily  solv¬ 
able,  on  large  ground  machines  or  in  non-real  time,  but 
have  not  yet  teen  solved  for  real-time  operation  in  a 
(small)  aircraft; 

ill)  some  of  the  problems  are  believed,  or  suspected,  to  be 
insolvable  within  acceptable  timescales/equipment/ 
budget /technology,  but  may  usefully  be  part-solved; 


To  achieve  continuous  useful  output  from  R  &  D  effort  towards 
diverse  functional  requirements,  using  diverse  and  in  some 
cases  immature  techniques,  requires  careful  attention  not  only 
to  the  functional  decomposition  of  the  MMA  family  but  to  the 
skill  and  technology  base  from  which  it  is  constructed. 


2  INTRODUCTION 

Combat  aircraft  are  being  equipped  with  increasingly  complex 
sensors,  counter-measures  and  weapons,  and  are  being  faced 
with  hostile  aircraft,  missiles  and  ground  installations  which  are 
likewise  more  complex.  At  the  same  time,  there  is  strong 
econonric  pressure  to  reduce  the  crew  In  number;  consolidation 
of  single-seat  as  the  norm  for  air-to-air  operation  and  an 
increasing  reqitirement  for  single-seat  operation  in  air-to-ground 
operations,  both  battlefield  support  and  even  deep  strike. 

A  need  for  computer  aids  to  the  crew  arises  from  two  directions. 

1 )  To  obtain  maximum  performance  from  these  increasingly 
complex  systems  involves  supporting  tasks  more  suited  to 
machmes  than  to  the  crew,  such  as  calculation  of  missile 
engagement  parameters,  electro-magnetic  signature  recog¬ 
nition  and  numerical  data  fusion. 

2)  The  Increasingly  complex  control  and  integration  of  these 
systems  together  vrilh  the  constraints  on  the  numbers  of 
the  crew  is  leading  (arKf  in  some  cases,  has  already  led)  to 
exMssive  crew  workload,  with  consequent  loss  of 
effedlverteas.  There  Is  therefore  a  need  for  the  computer 
to  assIsL  or  even  to  deputise  for,  the  human  in  tome  ^  the 
tasks  normally  conaUiered  the  province  of  man  rather  than 
machine,  such  as  aircrafi  systems  monitoring,  sensor  scan 
and  moding  oentrol,  and  tactical  decision  making. 

Such  computor  aldb,  which  assist  the  pflol  to  mattaga  toe  mis- 
aion,  have  coma  to  be  known  as  Mtoston  Management  Aids 
(MMAs).  They  are  /equirsd  In  order  If  achieve  and  to  maxim- 
IM  mission  eflscivertsss  and  vehide  survival. 


iv)  the  nature  of  the  solution  is  not  always  dear  -  this  can  be 
true  of  the  practical  solution  even  if  not  of  the  ideal  -  so  that 
white  we  know  the  problem  which  we  wish  to  solve,  and  we 
believe  that  technology  will  allow  a  solution,  we  may  not 
know  exactly  where  the  solution  lies.  We  will  recognise  it 
when  we  firid  it,  but  we  can  not  expect  that  we  will  always 
be  looking  in  precisely  the  right  place. 

Problems  like  these  may  be  the  stuff  of  life  to  research  and 
development  engineers,  but  are  not  so  welcome  to  businesses 
faced  with  an  R&D  requirement  which  is  both  tong-term  and 
uncertain.  These  considerations  colour  the  whole  approach  to 
the  planning  and  direction  of  MMA  research,  and  do  so  in  a 
way  which  oondittons  not  only  the  direction  of  the  research  but 
ateo  the  way  in  which  the  engineer  must  carry  it  out. 

This  paper  reviews  the  work  done  to  date  by  British  Aerospace 
(Military  Aircraft)  Limited  from  the  standpoint  of  the  above  con¬ 
siderations.  Drawing  on  experience  to  date,  it  considers  the 
MMA  family  by  function,  by  technology  and  by  timescale  to 
maturity,  and  highlights  some  of  the  questions  which  must  be 
addressed  by  project  customers  and  engineers. 

In  particular,  the  paper  considers  MMAs  which  assist  the  pitot 
with  tactical  planning,  both  for  attack  and  defence.  Such  MMAs 
are  currentty  envisaged  as  being  informative  or  advisory  rather 
than  autonomous  in  action,  and  are  known  as  Tacticai  Decision 
Aids  (TDAs). 


3  CUSSIFICATION  OF  MMAs 

MMAs  can  be  classified  by  mission  function,  by  the  type  of  ser¬ 
vice  rendered,  or  by  the  class  of  enabling  technology  (that  is.  by 
the  individual  or  group  skills  or  dtociplines  required  to  reafise 
toe  MMA). 

3. 1  Classification  by  Function 

Some  of  the  functions  which  MMAs  could  provide  ate  primary 
functions  cHtectod  at  the  mission  objectives,  such  as  attack 
planning;  others  are  supporting  functions  which  we  necessary 
to  acNeve  toe  objectives  of  the  mission  but  which  are  not 
sought  in  their  own  right.  An  example  of  the  latter  class  might 


The  advances  In  computing  tochrHtlogy,  boto  in  hardware  and 
In  toe  software  lechniquoe  to  which  toe  hardware  can  be 
applied,  already  altow  a  degree  of  avbome  oomputing  which 
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be  defensive  route  planning;  self-defence  Is  often  necessary  to 
achieve  attack  or  si^val,  but  combat  aircraft  are  not  purchased 
and  operated  for  the  purpose  of  defendirtg  themselves. 

For  the  purposes  of  this  paper,  if  both  primary  and  supporting 
functions  are  required  in  order  to  achieve  the  mission  objrctives 
in  the  expected  combat  environment  then  both  classes  are 
considered  as  mission  functions.  Some  supporting  crew-aiding 
functions  which  are  not  specific  to  the  combat  mission  rdle, 
such  as  general  utilities  management  can  also  be  admittad,  if 
they  are  modified  by  combat  mission  considerations  or  have 
common  enabling  te^niques. 

The  degree  of  need  for  an  MMA  will  vary  from  function  to  func¬ 
tion,  depending  on  the  function  itself  arid  the  suitability  of  the 
human  to  carry  it  out  on  the  scenario  (its  density,  typical  times¬ 
cale  and  technology  level),  and  on  the  numbsrs  of  crew  avail¬ 
able  (perhaps  dictated  by  other  factors  such  as  refit  and  re-use 
of  existing  ^rcraft,  or  a  rde  in  which  there  is  intense  but  short- 
duration  activity).  Accepting  for  he  present  that  sorrte  functions 
need  not  be  provided  by  MMAs,  we  can  identify  a  set  of  func¬ 
tions  which  can  be  provided  by  MMAs,  that  is,  functions  which 
could  be  given  to  a  competent  machine. 

•  Navigation; 

—  (re)routing  for  waypoint /target  timing; 

•  Systems  Management; 

—  Sensors  (with  tactical  and  fusion  awareness), 

—  Utilities  (communications,  engines,  fuel); 

•  Situation  Awareness, 

—  sensor  measurements, 

—  sensor  fusion  (state  and  attribute  measurements), 

—  attribute  inference, 

—  behavioural  inference, 

—  tactical  evaluation  and  prioritisation. 

•  Attack  Planning  and  Execution: 

—  air-to-air, 

—  air-to-ground,  fixed  target  -  (re)routing  only, 

—  air-to-ground,  mobile  target  -  attack  steering, 

—  air-to-ship  -  (re)routing  and  attack  steering, 

—  anti-submarine; 

•  Defence  Planning  and  Execution; 

—  air-to-air  -  aspect  and  energy,  decoys, 

—  surface-to-air  -  (re)routing,  screening,  decoys; 

It  is  perhaps  at  this  point  that  we  should  consider  exactly  what 
is  and  what  Is  not  an  MMA,  as  opposed  to  a  conventionally 
engineered  automation  or  software  function.  Territory  can  be 
Identified  which  dearly  belongs  or  which  dearly  does  not:-  a 
computer  programme  capable  of  antidpating  enemy  tactics, 
devising  effective  counter  plans  and  operating  a  oontrd  system 
to  cause  the  vehide  to  carry  them  out.  dearly  qualifies;  a  con¬ 
ventional  autopilot  almost  as  dearly  does  not  Where  exadly 
between  the  two  the  boundary  lies  is  a  matter  tor  debate  and  of 
arbitrary  definition. 

An  incomplete  definition,  but  which  is  sufficient  for  the  present 
discussion,  would  be  to  define  an  MMA  as  a  computer-based 
assistant  to  the  pilot  which  makes  use  of  'artifidal  inleMgence' 
(we  will  beg  the  definition  of  thatl)  w  unusuaR/  ingenious  pro¬ 
cessing  or  processing  requking  task-spedfic  liardware.  to  carry 
out  one  or  more  of  the  foNowIng  ta^  In  a  missiort-spedfic 
sense  -  manage  the  akcralt.  monitor  Its  status,  manage  the  sen¬ 
sors  and/or  assess  sensor  data,  advise  or  take  a  course  of 
action.  Thus  data  kision  is  admittad  M  H  indudos  tactical  aware¬ 
ness,  but  Is  exduded  if  it  comprises  only  a  Kalman  filer,  how¬ 
ever  advanced.  Aircraft  managamant  Is  admitted  H  It  demwKh 
tactical  Sexibilly  wHhin  die  mission  framework,  or  a  quaKtatively 
similar  type  of  IlexMRty. 

This  paper  wW  concentrate  on  MMAs  with  a  strong  tactical  con¬ 
tent.  in  terms  of  eMher  awareness  or  plannirtg  abfiity,  since  it  Is 
these  which  are  most  demandkig  in  terms  of  enabling  technol¬ 
ogy  and  mod  rastridive.  as  yet,  in  terms  of  lha  senfoe  level 


which  can  be  provided.  The  service  level  and  techrtology  con¬ 
cepts  are  considered  In  the  following  sub-sections. 

3 . 2  Classification  by  Service 

MMAs  can  be  divided  according  to  the  typo  of  service  which 
they  provide.  An  MMA  can 

A)  inform; 

B)  diagnose /assess; 

C)  advise /decide /control. 

Essentially,  this  progression  hangs  on  the  degree  of  authority 
which  the  crew  invest  in  the  MMA.  This  in  turn  is  a  funcfion  of 
the  trust  which  the  crew  has  in  the  MMA,  which  reflects  Its 
robustness  and/or  its  completeness. 

A  shortfall  In  robustness  may  result  from  an  inherent  weakness 
or  uncertainty  m  a  machine  intelligence  procedure  or  from  an 
inability  to  respond  adequately  to  circumstances  not  (fully) 
allowed  for  in  its  design  or  in  its  knowledge  base.  The  latter 
may  be  regarded  as  a  form  of  incompleteness,  which  would 
also  irx^lude  absence  of  algorithmic  or  logical  cover  for  sufficient 
drcumstances  (typically  an  incomplete  search  of  the  parameter 
space  or  of  sufficient  combinations  of  conditions). 

Tacfical  Decision  Aids  can  include  Tactical  MMAs  of  types  (A) 
and  (8)  and,  if  operated  in  an  advisory  rather  than  decisive 
capacity,  type  (C). 

At  the  informative  level,  an  MMA  can  already  be  made  fully  reli¬ 
able,  simply  because  its  scope  can  be  limited  as  much  as  may 
be  necessary  to  achieve  reliability.  The  MMA  is  simply  saying; 
"the  following  parameters  have  the  following  values".  The  pilot 
can  then  make  of  tl;is  what  he  will. 

The  diagnostic  or  assessing  MMA  requires  more  confidence  in 
its  abilities,  but  the  pilot  must  nevertheless  be  aware  of  its  limi¬ 
tations.  The  pilot  will  know  what  parameters  the  MMA  has 
taken  into  account  and  may  have  confidence  in  the  ability  of  the 
MMA  to  make  certain  defined  judgements  based  on  these 
parameters.  The  pilot  will,  however,  be  able  to  assess  the 
importance  of  those  parameters  or  effects  which  the  MMA  does 
not  take  into  account. 

The  distinction  between  ^Kfvisor  and  decider  is  one  of  degree 
rather  than  of  kind,  and  the  distinction  between  decider  and 
controller  is  one  only  of  implementation:  of  whether  the  neces¬ 
sary  wiring  and  hydraulics  are  present 

For  an  MMA  to  decide  on  a  course  of  action,  there  must  be 
grounds  for  believing  that  the  advice  is  sound.  If  a  comprehen¬ 
sive  questioning  of  the  MMA  is  possible,  then  the  MMA  in  effect 
reduces  to  type  (B)  —  the  pilot  can  make  his  own  fbal  judge¬ 
ment.  It  time  does  not  permit  such  a  questioning,  then  the  pitot 
must  either  accept  or  reject  the  MMA’s  advice  in  loto.  In  order 
to  accept  it,  he  has  to  assume  that  all  relevant  factors  have 
been  correctly  taken  Into  account 

Simple  systems,  especially  mechanical  ones,  have  (or  long  had 
such  authority,  autopilols,  landing  systems,  fire  extinguishers, 
IFFN.  We  have  a  long  way  to  go.  however,  before  the  machine 
win  reliably  outperform  the  best  humans  In  air  combat 

3.3  Classification  by  Technology 

We  can  consider  a  sequence  of  capabHilies  which  we  can  seek 
of  MMAs. 

A)  conventional  -  number-crunching  which,  sRlhough  possibly 
complex  and  inventive  in  its  conception.  Is  uninventive  In 
its  execution  within  the  computer; 

B)  smart  -  logic  and  number-crunching  giving  superficlaly 
inteRigent  processing  but  always  responding  to  foreseen 
circumstances  in  a  foreseen  way; 

C )  inteRigent  -  the  MMA  wRI  hattdto  In  a  reasortabla  wm,  cir¬ 
cumstances  which  have  not  been  yyired  in'  (tethou^  they 
may  be  only  variations  on  a  pre-consideted  pailm). 
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Analogies  to  (A)  to  (C)  can  be  found  in  the  pilot  himself.  If  (A) 
corrMponds  to  unconscious  operations  such  as  local  musde 
control.  Indudfog  reflexes,  or  to  the  initial  sum-and-difference 
ale.  processing  ot  retinal  signals,  then  (B)  would  correspond  to 
sub-conscious  processes  such  as  mus^  co-ordinalion  and 
sequendrrg  or  to  optical  pattern  decomposition  and  recognition, 
and  (C)  would  correspond  to  conscious  thought  and  reasoning. 

Examples  within  TDAs  and  related  functions  would  be  (A)  the 
statisMcat  tosion  of  sensor  measurements,  (B)  the  fusion  of  state 
data  with  partialy  confHciiirg  attribute  arid  operational  intelt- 
gence  data,  (C)  the  anticipi&on  of  possible  tactical  moves  by 
the  targets  arid  the  consequences  thereof. 

It  is  reasonable  to  suppose  that  the  tactical  MMA  will  require 
capabiHlies  of  type  (C),  whereas,  moving  upstream  in  the  data 
flow  towards  the  sensors,  the  computer  will  have  capabilities 
moving  towards  type  (A). 

Taking  for  granted  the  advent  of  powerful  airborne  computers, 
and  assuming  that  the  power  of  these  will  irtorease  in  Ihe  next 
few  years  at  feast  until  comparable  with  the  light-weight 
machines  now  avaSabte  on  the  ground,  we  can  consider  the 
tools  and  techniques  available  to  the  research  and  development 
engineer  to  provide  these  capabilities  in  an  MMA: 

•  conventional  geometric,  statistical,  etc., -computing: 

•  recent  techniques  using  conventional  computing,  many  of 
which  are  still  being  developed,  such  as  Kalman  filtering 
or  the  more  ingenious  applications  of  Dempster-Schaeffer 
analysis  within  quasi-AI  logical  frameworks; 

•  artificial  intelligence  techniques  which  reduce  to  conven¬ 
tional  computing,  eg.  Fuzzy  logic  or  (arguably)  A*  search; 

•  out-and-out  new-wave  techniques,  such  as  knowledge- 
based  systems  in  which  the  knowledge  base  is  ptxicessad 
by  an  ‘inferetroe  errgine',  or  neural  networks; 

•  high-level  progranuner-friendly  sofhvare  environments  and 
objective  languages; 

As  we  progress  down  the  list  we  move  into  areas  of  greater 
power  to  solve  'intelligenoa'  demanding  problems,  but  at  the 
same  time  we  move  into  realms  of  less  experience,  less  under- 
starKtng  and  less  proven  integrity.  Fuzzy  logic  is  ‘rigorous'  in 
the  sense  that  it  is  mathematically  sound  and  uses  conventional 
computing  logic  with  veririable  software,  but  is  sometimes  sub¬ 
ject  to  customer  suspidon.  While  Inference  engines  are  them¬ 
selves  formally  predtotable,  their  interactions  with  their 
knowledge  bases  are  not  always  predictable  and  the  system  as 
a  whole  may  therefore  rwt  be  verifiable.  As  yet  they  are  often 
too  inefficient  for  demanding  real-time  problems.  Sknilarty,  the 
highest  level  languages  and  environmeniB  can  have  problems 
of  both  efficiency  and  retiability. 

3 . 4  Tactical  MMA  Technoioov  vs  Function 

Figure  1  illustrates  an  outline  architecture  containing  sensor 
fijsion,  situation  assessment  sensor  manager  and  tactical 
planner.  The  a.  p  notation  corresponds  to  that  of  reference  2. 

(The  term  Situation  Assessment  is  used  with  stightly  different 
meanings  in  different  countries  and  organisations,  coveting  one 
or  nwre  of  the  functions  grouped  together  in  the  figure  from  ini¬ 
tial  Sensor  Fusion  through  to  Target  Prioritisation.  Boundaries 
are  difficult  to  define,  and  the  terms  Situation  Awarerress  and 
Target  Prioritisation  are  used  in  this  paper  where  any  degree  of 
pteolsion  is  required.) 

Not  al  the  eiemenis  In  figures  (1)  and  (2)  are  MMAs,  but  dearly 
all  are  closely  related,  and  their  technologies  merge. 

i )  Fusion  of  sensor  measurements,  tociudng  track  estimation, 
may  wati  be  achieved  by  fixed  mattwmalical  formulae 
(todudtog  hanctitog  of  uncertainlies  or  corttradictlons):  K  Is 
Nhaly  to  ba  implernanted  as  a  robust  and  verffiabto  function 
of  tw  aqulpinoni  rather  toan  toa  ovsraM  syslam-oum-rflte 
and  is  not  assantaly  an  MMA  funetton; 

I)  Fusion  with  mission  brtofing  date  a  Hwiy  to  require  tochi- 
ston  of  tedicat  judgsmante  atong  wHh  handbtg  of 


uncertainties  or  contradictions,  and  thus  moves  towards 
intelligent  judgement  rather  than  mechanical  function:  for 
the  present,  it  is  considered  to  be  an  MMA  function, 
although  whether  part  of  a  tactical  decision  aid  will  depend 
on  the  degree  of  behavioural  data  which  is  processed  and 
on  how  that  data  is  subsequently  processed  or  displayed. 

iii)  Target  Prioritisation  can  be  Implemented  at  almost  any 
desired  level,  from  the  simplest  range  and  range-rate  for¬ 
mulae  to  deepest  tactical  reasoning  weighted  against  the 
mission  objectives.  Funciionaly,  it  can  be  cottsidered  to  be 
a  Tactical  Decision  Aid  at  any  level. 

iv)  The  Sensor  Manager  is  an  MMA,  although  not  a  TDA. 

v)  Attack  Planning  is  clearly  a  TDA  furtetion. 

The  relationship  between  the  Sensor  Processing  and  MMA 
functions  and  the  type  of  technology  they  require  is  illustrated 
by  the  matrix  of  figure  2.  It  is  not  claimed  that  the  characterisa¬ 
tions  given  by  the  figure  are  absolute,  but  they  irxticate  a  gen¬ 
eral  drift  towards  a  need  for  Al  technology  which  occurs  as  we 
move  functionality  to  the  right  in  figure  1 . 

The  Sensor  Fusion  and  Manager  systems  are  included  for  com¬ 
pleteness.  Although  the  fomner  is  not  an  MMA  and  the  latter  is 
not  strictly  a  Decision  Aid,  the  whole  famtiy  are  intimately  con¬ 
nected  and  the  Sensor  Manager  is  a  Mission  Management  Aid 
which,  in  a  combat  environment,  requires  tactical  knowledge. 
Depending  on  the  amount  of  autonomy  which  the  Sensor 
Manager  is  required  to  carry,  there  is  scope  for  greater  or 
lesser  degrees  of  ‘intelligent’  tactical  knowledge.  In  terms  of  the 
technology  required  to  implement  it,  the  Sensor  Manager  there¬ 
fore  forms  a  Mdge  between  the  largely  numerical  processing 
functions  upstream  and  the  largely  logical  processing  functions 
downstream. 


4  THE  APPROACH  TAKEN 

MMA  developments  within  BAe(MAL)  are  progressed  by  goal- 
driven  prototyping  prefects  backed  up  and  guided  by  a  continu¬ 
ing  programme  of  requirements  analysis. 

4 . 1  The  Requirements  Analysis 

The  general  requirement  for  MMAs  is  dear  from  experience  in 
the  design  and  operational  support  of  combat  aircraft  to  date 
and  from  discussion  with  aircrew.  However,  to  clarity  and  refine 
the  detail  and  priorities,  British  Aerospace’s  overall  MMA  pro¬ 
gramme  includes  a  Requirements  Definition  activity.  This 
involves  aircrew  with  tactical  and  Human  Factors  spedalists  in 
mission  simulations,  designed  to  identify  the  priority  tasks  to  be 
assigned  to  MMAs  and  to  identify  which  aspects  of  these  tasks, 
including  the  extent  and  the  balance  of  autonomy,  which  crew 
would  wish  to  delegate  to  the  machine.  The  results  from  these 
investigations  guide  the  selection  of  topics  and  objectives  for  aH 
MMA  programmes,  inciuding  those  on  Tactical  Decision  Aids 

For  overall  tactical  planning  MMAs,  particularly  air-to-air.  where 
some  problems  are  believed  not  to  be  solvable  in  the  short-term 
with  present  knowledge  and  (akbome)  hardware,  the  objective 
has  been  to  develop  an  understanding  of  the  nature  of  the  logic 
and  mathematics  of  possible  solution  techniques,  the  quaRty  of 
data  requited,  the  amount  of  conqnitation  and  date  transfer 
required,  and  the  processing  architectures,  in  ptepara^  for 
longer-term  programmes. 

4  ■  2  Prototypino  Projects 

The  objectives  derived  and  prioritised  by  the  Requirements 
Research  programme  guide  the  evolution  of  an  overaR  strategic 
MMA  programme,  within  which  individual  goals  are  pursued  by 
demonstrator  sub-jxogrammes.  Each  such  sub-programme 
comprises  an  iterative  cycle  of  brainstorming,  prototyping  and 
evaluation,  thus: 

I)  racontmendations  from  previous  cycle  plus  new  ideas; 

I)  design  of  next  prototype; 

IR )  impfementalion  on  a  workstation; 
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iv )  initial  appraisal  -  possible  return  to  step  (i); 

V)  implementation  on  combat  simulator  or  other  simulation 

vi )  mission  simulation  and  aircrew  appraisal  and  comment 

Consideration  has  been  given  to  conventional,  procedural  pro¬ 
cessing,  and  to  declarative  and  AI/KBS  techniques.  It  is 
believed  thm  convenllortal  impiementation  will  be  required  for 
airborne  application  in  the  short-to-medium  term,  although  this 
will  not  preclude  'conventional'  implementation  of  some  Al  tech¬ 
niques.  It  is  also  befieved  that  AI/KBS  win  be  necessary  for 
mwy  of  the  more  complex  and  'intelligent'  later  MMAs.  There¬ 
fore,  a  balance  is  maintained  between  the  two  at  the  research 
stage,  including  the  use  of  procedural  functions  within  an  other¬ 
wise  KBS-shell-based  program.  Most  work,  however,  is  carried 
out  in  conventional  languages,  for  possible  short-term  imple¬ 
mentation,  for  efficiency  of  execution  (necessary  for  simulation 
assessment),  and  for  compatibility  with  coRaborating  depart¬ 
ments'  extsting  equipment  and  expertise. 

The  C  language  has  been  found  to  be  the  most  suitable  for 
experimental  and  prototype  coding.  It  gives  the  greatest  flexibil¬ 
ity  of  interface  to  the  workstations,  and  requires  fiWe  or  no  code 
modification  on  transfer  to  the  disparate  processors  of  the 
avionic  and  flight  simulation  rigs.  The  MUSE  language  (a 
derivative  of  Prolog)  is  used  for  KBS  elements.  The  developed 
prototypes  wifl  enable  design  specifications  to  be  drawn  up  from 
which  'production'  MMAs  would  be  implemented  in  languages 
such  as  ADA. 

British  Aerospace  is  pursuing  MMA  development  across  the 
range  of  functions,  including  Tactical  MMAs  and  the  related 
Sensor  Managerttent  functions.  BAe  is  a  participant  in  a  Joint 
Venture  programme  with  GEC,  Smith's  Industries  and  RAE,  dis¬ 
cussed  in  a  later  paper  in  this  symposium  (reference  1).  The 
Joint  Venture  has  concentrated  on  deferrce  against  ground 
threats,  while  BAe's  in-house  effort  has  concentrated  on  air-to- 
air  combat 

Exploratory  work  has  been  conducted  on  air-to-air  TOAs  of  a 
type,  although  not  a  degree,  which  would  allow  an  MMA  to  con¬ 
trol  the  aircraft  in  BVR  air  combat  Development  to  a  degree 
which  would  allow  such  an  MMA  to  enter  service  is  seen  as  a 
comparatively  long-term  goal.  Work  is  being  paced  to  maintain 
a  balance  in  the  rate  of  development  of  Al  and  KBS  techniques, 
of  tactical  aigorfthms,  of  sensor  and  counter-measure  technol¬ 
ogy.  and  of  available  airborne  hardware. 

Relerettoe  2  describes  a  prototype  TDA,  COMTAC,  which  uses 
oonventioftal,  or  Procedural,  computing  techniques.  Since  the 
publicallon  of  reference  2,  COMTAC  has  been  further 
developed  and  has  been  implemented  in  the  Air  Combat  Simu¬ 
lator  at  Warton.  In  a  patallei  activity,  a  Knowledge-based  TDA 
prototype,  KATS,  explored  the  appication  of  KBS,  and  the 
TACAID  programme  (reference  3)  addressed  the  integration  of 
the  two  approaches. 

Recognising  the  prioritiee  of  Vie  next  roloaso  of  service  aircraft 
effort  is  concentrating  on  MMAs  wiVi  shorter  lead  times,  in  par- 
ticutar  on  Sensor  Management  Sttuatlon  Awareness  and  Attack 
Planning  Aids  of  the  informative  rather  than  decisive  type,  type 
(A)  of  section  3.2.  TDAs  are  being  developed  which  process 
parametsrs  of  the  measured  scenario  and  preoent  derived  tacti¬ 
cal  information  to  the  crew  in  a  concise  and  quickly  assimiiable 
form.  These  TDAs  are  essentiaily  real-time  visual  aids  in  which 
the  pilot  can  see  taclicaf  portrayals  of  Vie  baiVe  scenario  from 
which  he  can  make  the  tactical  judgements. 


5  PROQRE88  AND  lEBSONS 

Rsesnt  years  have  seen  steady  advencss  in  knowtsdge  and 
eapabM^.  In  some  areas,  success  and  progress  exeesdsd  ffiat 
which  wee  anflcipelsd,  wMa  in  others,  Ineidtabiy,  some  retreat 
wid  oonspididon  WM  lofosd.  In  dm  Inttsf  csms  nlrnott  m 
much  as  in  Vie  termor,  hnowtedge  was  gained  sTflch  was  of 
value  in  planning  Vie  next  stop.  Usualy.  when  someWng  was 
found  not  to  work.  It  led  quiddy  to  flndbig  out  what  does  work. 


5.1  MMA  Requirements  Analysis 

Although  MMA  Requirements  had  been  pursued  for  a  number 
of  years  by  discussion,  the  experimental  activity  spedficafly 
drected  towards  this  began  In  the  summer  of  1990,  when  Vie 
necessary  simulation  facility,  the  Part  Task  Simulator  (PTS)  at 
Dunsfoid,  was  sufficiently  developed. 

The  PTS  is  designed  tor  rapid-prototyping  of  man-machine 
Interface  and  MMA  requirements  definition  studes  within  simu¬ 
lated  missions.  It  gives  a  cockpit-iiko  environment  with 
computer-generated  outside-world  graphics,  in  which  pilots  can 
'fly'  simulated  combat  missions,  it  can  be  linked  to  an 
advanced  avionics  development  cockpit  when  more  realistic 
and/or  two-aircraft  simulations  are  need^. 

initially,  an  MMA  is  represented  by  human  operators.  This 
serves  two  purposes:  it  avoids  biasing  the  trial  by  the  pre¬ 
conceptions  or  limitations  Inherent  in  any  particular  man- 
machine  interface,  and  it  avoids  the  problem  that,  in  general, 
the  MMAs  whose  requirenients  are  to  be  investigated  will  not 
yet  exist!  The  pilot  is  able  to  delegate  such  functions  as  he 
chooses  to  the  MMA:  progressively,  the  real  (silicon)  MMAs  are 
introduced  to  reproduce  the  functions  which  the  pilot  has 
delegated  to  the  human.  When  the  silicon  MMA  is  in  place,  an 
integrated  investigation  of  requirements  and  solution  can  be 
progressed. 

Trials  so  far  have  ostablished  patterns  of  crew  preferences  for 
how,  when  and  to  what  extent  the  crew  would  wish  to  delegate 
control  of  functions  such  as  target  selection  and  sensor  moding 
to  the  MMA. 

There  are  types  of  MMA  operation  in  which  the  reduction  in  the 
pilot's  workload  obtained  by  the  MMA  can  be  lost  to  the 
increase  in  the  pilot's  effort  in  controlling  and  monitoring  not 
only  the  MMA  itself,  but  the  status  of  the  pilot/MMA  partnership. 
It  was  found  that  certain  patterns  of  delegation  could  lead  to 
confusion  about  who,  pilot  or  MMA,  controlled  what  function, 
while  with  other  patterns  of  delegatbn  the  pilot  retained  a  dear 
understanding  of  how  the  man-machine  partnership  was  operat¬ 
ing.  Narrow  and  deep,  but  movable,  delegation,  can  lead  to 
unproductive  workload  to  monitor  the  delegation  state  itself. 
This  is  usually  relieved  by  a  system  of  progressively  deepening 
broad  delegat’on. 

The  crew  requirements  and  workload  studies  also  underline  the 
need  to  maintain  a  balance  between  the  two  prime  objectives  of 
MMA  research:  on  the  one  hand  to  reduce  the  workload  of  the 
crew  toced  with  increasingly  complex  systems,  on  the  oVier 
hand  to  optimise  the  perfomiance  which  the  crew  can  obtain 
from  these  systems.  It  would  be  all  too  easy  to  fill  the  cockpit 
vrith  computer-based  aids  to  weapon  system  management 
which  could  achieve  excellent  performance  ...  if  the  pilot  had 
suffident  hands  and  eyes  and  ears  and  speed  and  concentra¬ 
tion  to  be  able  to  operate  them! 

The  requirements  finrflngs  have,  on  the  whole,  supported  the 
pragmatic  decision  to  proceed  at  a  measured  pace  with  the 
more  intelligent,  type  (C),  TDAs,  at  least  for  air-to-air  combat 
They  serve  also  to  ensure  that  we  do  not  lose  sight  of  the 
importance  of  the  man-machine  interaction  in  our  quest  for  ever 
more  capable  machines. 

5 . 2  Tacticaf  Planning  Aids 

The  COMTAC  demonstrator  discussed  bi  section  4  has  been 
fristatted  in  the  Air  Combat  Simulator  at  Warton.  and  has  been 
flown  by  pilots  in  scenarios  containing  computor-conirofled 
esoortod  bomoer  raids.  Flying  Vw  prototype  has  given  p^  a 
datum  from  w.iich  to  comment  on  its  tacV^  bshaviour  and  from 
which  it  is  possMs  to  kfenVfy  isaluias  which  pflols  oonsidsr  to 
be  of  value  in  Vieir  own  right  Aiiaady,  spin-off  banaflis  have 
been  obtained:  lor  axampis,  dtoplays  design  work  for  Via  frial 
has  givsn  dbpiays  for  muWpla-tatgst  missila  lira  oonbol  which 
are  oonsidofad  to  be  an  advance  on  prevtous  dasigna. 

The  TACAID  programma  to  combine  Prooedural  and  Daclaia- 
flve  approaches  to  MMA  dssign  is  detorffwd  bi  an  aariiar  paper 
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of  this  ^mposkjm  (reference  3). 

A  rtu^or  spin-off  from  ttw  COMTAC  programme  has  been  an 
MMA  which  was  in^ly  sin^  to  COMTAC  in  cortcept  but  with 
modfied  dspiays,  superimposing  on  the  attack  map  dsplay. 
tactical  paramMars  related  to  a  simpler  but  denser  set  of 
ptofltes.  This  MMA  became  known  as  TACMAP. 

TACMAP  was  weR  received  by  pitots,  but  with  recommertda- 
lions  for  improvement  These  recommendations  evolved 
steadily  into  a  substantial  change  in  concept  In  oollaboratton 
with  pRots  and  MMi  spedalisls,  the  MMA  team  has  evolved 
TACMAP  away  from  Its  COMTAC  roots  i(tto  a  quite  distinct  TDA 
family,  with  potential  to  mature  from  concept  RAD  to  product 
devetopment  witHn  two  or  three  years. 

The  oonce^al  changes  which  slowed  TACMAP  to  grow 
rapidly  towards  maturity  involved  in  essertce  moving  away  from 
the  arJvisory,  type  (C)  TDA,  to  concentrate  on  informative  and 
dagnoetic  ^pes  (A)  and  (B),  with  the  consequent  abilty  to  pro¬ 
gress  effectively  using  otRy  technology  types  (A)  and  (8). 
advanced-conventional  and  Smart.  The  explicit  steering  advice 
has  been  rfropped,  and  emphasis  has  been  placed  on  the  car- 
togram,  showing  tactical  parameters  in  a  time-projected  sense 
across  the  battte  area.  It  has  been  found  that  oonsiderabla 
abstraction,  even  ambiguity,  can  be  included  in  the  tactical 
meaning  of  the  parameters  yet,  with  practioe,  the  pilot  can 
respond  to  the  display  to  obtain  more  successful  combat  steer¬ 
ing  than  without  the  MMA.  This  means  that 

i)  the  definitions  of  many  parameters  modelling  physical  or 
tactical  quantities  can  be  greatly  corrupted  towards  great 
algebraic/trigonometric  simplicity  (with  carel),  allowing 
ra^d  updates; 

ii )  the  uncertain  behaviour  of  the  enemy,  and  multiple-choice 
by  own  pilot  further  into  the  engagement,  need  not  be 
represented  rigorously  or  the  possibilities  dsplayed  indivi¬ 
dually;  they  can  be  amalgamated  into  composite  parame¬ 
ters  having  suitable  cueing  behaviours  as  decision  points 
approach  or  uncertainties  arise. 

The  abstraction  principles  have  been  demonstrated  in  simula¬ 
tions  to  be  sound,  enough  has  been  done  on  the  workstations 
to  prove  in  concept  that  the  caveats  under  Item  (ii)  above  can 


be  satisfied,  and  TACMAP's  tolerance  to  sensor  enor  has  been 
shown  to  be  satisfactory. 

A  further  spin-off  from  the  COMTAC  programme  has  been  a 
body  of  work  from  which  to  dMH  rapid  algoitihms,  embodying  a 
degree  of  tactical  understanding,  for  preliminary  priorWsatfon  of 
threats  and  targets.  This  can,  in  appropriate  modes,  serve  a 
number  of  purposes.  It  can  support  the  prioritisation  capabWty 
in  the  sensor  manager.  It  can  provide  a  dspiays  fHter  for  the 
crew  and  for  TACMAP,  and  it  wRI  give  a  data  reduction  filter  for 
the  comprehensive  tactical  planning  MMAs  which  wHI,  In  time, 
enter  sendee. 


6  CONCLUSIONS 

Overall,  It  has  been  found  that  operating  within  the  consirainis 
of  current  hardware  and  software  technology, 

1 )  rapid  progress  can  be  made  towards  TDAs  which  can  be 
ambitious  In  their  intended  performance  and  operational 
effectiveness,  provided  they  do  not  attempt  to  push  too 
quieWy  into  the  domain  of  real-time  inteWgence. 

2)  Steady  progress  can  be  made  with  a  reasonable  level  of 
investment  into  TDAs  which  require  a  high  degree  of  real¬ 
time  intelligence,  provided  that  the  MMA  programme  does 
not  attempt  to  push  too  far  ahead  of  the  world  level  of 
technology  within  the  AI/KBS  community.  To  advance  fas¬ 
ter  requires  that  the  MMA  community  a^ance  a  range  of 
techniques  which  have  application  in  other  areas,  thus  tos- 
ing  the  general  synergy  between  Applications  research 
and  wider  Enabling  Technology  research. 

3)  Combining  the  above  approaches  gives  a  consistent 
framework  for  the  activity  as  a  whole.  The  longer-term 
goals  prompt  useful  and  achievable  shorter-term  sub¬ 
systems,  while  the  self-determining  sub-systems  generate 
enabling  technology  tmd  an  overall  ‘feel'  for  the  problems 
to  feed  the  longer-term  projects. 

4 )  The  requirements  (i)  to  enable  the  crew  to  maximise  sys¬ 
tem  performance  and  (ii)  to  keep  the  crew  workload  within 
acceptable  bounds  can  not  be  addressed  independently. 
Addressed  independently,  each  can  adversely  affect  the 
other. 
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Discussion 

1.  G.  Bourassa,  Canada 

Please  clarify  the  designation  of  TACAID  as  a  "selection” 
mechanism. 

Author 

I  believe  that  this  designation  was  made  in  Paper  7,  which  I 
presented  «i  b  '.half  of  Dr  Roberts,  not  in  Paper  17. 1  believe 
that  the  point  Dr  Roberts  wished  to  make  was  that,  rather 


than  searching  the  parameter  space  for  an  optimum 
solution,  with  the  option  to  generate  alternative  sub- 
optional  solutions  (e.g.  A*),  the  TACID  heuristics  “select” 
plans  and  plan-steps  according  to  trigger  states,  without 
cross-comparison  of  competing  possibilities.  (Although 
there  is  scope  for  local  optimization  when  the  physical 
parameters  of  the  plan,  such  as  speed,  height,  heading,  etc., 
are  algorithmically  quantified  for  implementation.)  Thus 
any  one  state  of  the  scenario  and  of  the  rule  base  will 
^nerate  (select)  one  and  only  one  plan  description. 


e  Btffteh  Crown  Copyrtght  1991  /MOD 

PubliBhad  with  tfw  pormlaalan  of  tfw  Cenfrofter  of  Hor  Britannic  Majoat/a  Statonory  Offioa 


4—  control  data  <— 


descriptive  data  => 


Figure  1 :  Illustrative  Sensor  +  TDA  Architecture 
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SYSTEMS  EXPERT  EMBARQUABLE  SUR 


AVION  D'ARMES  POUR  EVALUATION 


DES  PERFORMANCES  TEMPS  REEL 


D.  SERVEL  -  A.  HAVRE 
DASSAULT  ELECTRON I QUE 
55  Qual  Marcel  Dassault 
92214  Saint-Cloud 
France 


1.  RESUME 


Cet  article  traite  des  qu^^tions  d'embar- 
quabilite  de  fonctions  d' irttelliqence 
artificielle.  II  detaille  I'fetude  effectuee 
par  DASSAULT  ELECTRON I QUE  et  ^ASSAULT 
AVIATION  visar.t  a  evaluer  les  ^rformances 
temps  reel  que  requiert  1 'embarquaUailite 
d'un  systeme  expert  avion ique. 

Une  maquette  de  systeme  expert  d'aid*  a  la 
comprehension  des  pannes  et  de  gestioiV  des 
procedures  d'urgence  a  bord  du  demonstra- 
teur  RAFALE  A  a  fourni  le  support  de  cette 
etude.  \ 

Les  conclusions  positives  de  1 'etude  et  les 
perspectives  futures  qu'elle  a  degagees 
constituent  I'objet  de  cette  publication. 


2.  APPORT  DES  TECHNIQUES  D' INTELLIGENCE 


ARTIFICIELLE  POUR  L'ASSISTANCE  AU  PILOTS 


2.1  contexte  de  1' etude 


L* etude,  objet  de  cette  presentation,  a  ete 
r^allste  conjointement  par  DASSAULT 
BLECTRONIQUE  et  DASSAULT  AVIATION  dans  le 
cadre  d'un  march^  finance  par  le  service 
Technique  des  T^lteoomunications  et  des 
Equipements  a^ronautiques  (STTE)  de  la 
Ml^^tion  O^nArale  pour  I'Armement  (DGA). 

Dans  les  probldmes  d'^valuatlon  de  I'^tat 
des  diff^rents  syst^mes  de  1 'avion  (moteur, 
qAn^ratlon  ^lectrique  et  hydraulique, 
frelnaqe,  etc.),  un  point  particuli^re- 


ment  important  pour  assister  le  pilots  au 
cours  de  sa  mission  est  le  filtrage  des 
alarmes  et  la  gestion  des  procedures 
d ' urgence . 

Ceci  se  traduit  par  1’ analyse  de  1' inciden¬ 
ce  de  la  panne  pour  informer  le  pilots,  lui 
conseiller  les  actions  limitant  1' Impact  de 
la  panne  et  le  prevenir  des  reductions  du 
domaine  d'utilisation  de  I'avion. 

Dans  cette  optique,  on  s'interesse  essen- 
tiellement  aux  dependances  inter-systemes 
(la  generation  electrique  est  par  example 
resultants  de  1 ' entrainement  des  alterna- 
teurs  par  les  moteurs ) .  Le  raisonnement  lie 
a  ce  problems  comprend  chronologiquement 
trois  etapes  ; 

.  Effectuer,  en  fonction  des  phases  de  la 
mission,  un  filtrage  initial  intelligent 
deS..  pannes  pour  ne  conserver  que  1' infor¬ 
mation  essentielle  en  cabine  (la  panne 
la  pills  critique  en  general). 

.  Evaluer  les  consequences  de  la  panne 
origins  et  des  anomalies  resultantes  de 
facon  a  faii^e  face  le  mieux  possible  a  la 
nouvelle  configuration. 

.  Proposer  les  ac\ions  curatives  selon  les 
procedures  d'urg^ce  de  telle  sorts  que 
I'on  puisse  presei^er  au  maximum 
1' integrity  de  I'av^n,  ce  qui  suppose 
souvent  des  llmitati^s  de  domaines. 

\ 

Un  tel  raisonnement  fait  e)|?pel  A  la  con- 
naissance  des  systAmes  et  Aquipements 

de  I'avion  et  de  son  SystAme\e  Navigation 
et  d'Attaque  (SNA).  ' 

Apporter  une  solution  A  ce  probleme  impli- 
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que  de  plus  la  prise  en  compte  de  toutes 
les  contraintes  liees  au  temps.  II  est  en 
effet  Indispenscible  de  proposer  des  actions 
avec  des  temps  de  reponse  acceptables  pour 
le  pilote.  Ceci  ne  veut  pas  dire  que  ces 
temps  de  reponse  doivent  obligatoirement 
etre  tres  courts,  mais  qu'ils  doivent  etre 
compatibles  avec  le  deroulement  reel  d'une 
mission  et  avec  les  imperatifs  de  securite. 

De  plus,  les  connalssances  utilisees  sont 
suffisamment  larges  pour  inclure  des  repre¬ 
sentations  fonctionnelles  des  equipements, 
des  connalssances  de  surface  sur  les  dys- 
fonctionnements,  des  connalssances  sur  le 
principe  de  deroulement  des  missions,  et 
enfin  des  connalssances  d’ergonomie  et  de 
comportement  pilote. 

2.2  L'approche  intelligence  artificielle 


L' intelligence  artificielle  peut  apporter 
de  nombreuses  reponses  a  ces  problemes. 

Tout  d'abord,  la  qualite  des  mecanismes 
d’ inference,  aujourd'hui  bien  rodes,  repond 
bien  a  la  complexite  des  raisonneraents  que 
I'on  veut  mener  a  bien.  Les  progres  des 
techniques  de  modelisation  des  connaissan- 
ces  lies  aux  avancees  en  matiere  de  logique 
permettent  de  bien  saisir,  sans  la 
restreindre  par  un  moule  trop  pesant,  la 
diversite  des  connalssances.  Enfin,  I'ap- 
proche  nouvelle  du  point  de  vue  de  la 
prograimnation,  introduite  par  les  systemes 
a  regies  de  production  et  les  langages 
orientes  objets  doit  permettre  d' assurer  la 
modular ite  et  la  flexibilite  indispensables 
a  de  telles  applications. 

Ainsi,  les  techniques  et  les  langages  de 
1' intelligence  artificielle  permettront  de 
modeliser  certains  ralsonnements  que  doit 
faire  le  pilote  de  manl^re  a  alleger  sa 
tAche  dans  un  environnement  agressif  ou  de 
1' alder  dans  des  operations  complexes, 
ladxjrieuses  ou  repetitives,  ceci  grace  a 
une  transcription  dans  un  calculateur  de 
1 ‘expertise  et  de  1 'experience  acquise  par 
les  operationnels ,  I'avlonneur  et  les 
equlpementiers . 


3.  PROBLEMES  TEMPS  REEL  IHHERENTS  A 


L‘ INTELLIGENCE  ARTIFICIELLE  EMBARQUEE 


Tout  systeme  fonctionnant  en  temps  reel 
doit  faire  face  a  deux  types  de 
contraintes  : 

.  Les  contraintes  propres  aux  donnees  a 
tralter  :  les  informations  sont  en 
general  heterogenes,  parfois  incompletes, 
Incertaines  ou  contradictoires ,  et  dans 
tous  les  cas  changeantes  parce  qu’a 
valeur  temporelle.  A  cette  nature  intrin- 
seque  des  donnees  s'ajoutent  en  plus  les 
contraintes  d'echanges  par  messages, 
synchrones  ou  asynchrones,  aleatoires  et 
surtout  independants  des  traitements. 

.  Les  temps  de  reponse  impart is  et  les 
delais  accordes  pour  1' execution  des 
traitements  :  un  systeme  temps  reel  doit 
pouvoir  faire  face  a  des  pointes  en 
charge  de  calcul,  gerer  des  taches  mul¬ 
tiples,  des  conflits,  des  interruptions. 
Ctette  maitrise  necessaire  de  1 'execution 
implique  done  des  capacites  de  traitement 
elevees,  des  traitements  geres  par  taches 
de  priorites  differentes,  des  niveaux 
d' interruptions  dans  ces  traitements, 
voire  un  moniteur  de  gestion  des  taches. 

A  1' inverse,  un  systeme  expert  est  jaeu  pre¬ 
pare  a  affronter  de  telles  contraintes  : 

.  Les  informations  sont  plus  souvent  sym- 
boliques  que  numeriques,  les  donnees  ont 
en  general  une  valeur  durable,  si  ce 
n'est  definitive,  ce  qui  fait  que  dans  la 
plupart  des  cas  les  problemes  de  non- 
monotonie  sont  ecartes. 

.  Les  performances  ont  un  caractere  diffi- 
cilement  previsible,  en  particulier  en  ce 
qui  concerne  les  temps  d' execution  des 
ralsonnements,  puisqu'ils  dependent  des 
strategies  utilisees,  de  I'ordre  dans  le- 
quel  sont  traitees  les  informations  . . . 

Le  probl^me  de  la  memoire  vient  ^galement 
s'ajouter  4  ces  contraintes.  Les  applica¬ 
tions  lA  sont  en  general  "gourmandes”  en 
memoire,  et  utilisent  toutes  un  "garbage 
collector"  pour  leur  gestion.  Ceci  a  pour 
consequence  : 


Un  cout  en  temps  de  recuperation  de  la 


memoirc. 

.  [.a  n6ccs3it6  d' avoir  uno  gostion  dynami- 
que  de  la  m6moire. 

.  Dos  difficultds  d'interfacage  avec  lea 
langages  algorithmiques,  lea  informations 
n'ayant  pas  une  place  allou6e  fixe. 

.  Dos  probl6mes  de  compl6tude  si  I'on  ne 
dispose  que  d'une  mfemoire  limit6e. 

.  Un  temps  d'ex6cution  finalement  non 
previsible. 

Dans  lo  domaine  embarque,  les  contraintea 
evoqueos  sont  cruciales  et  I'lA  doit  s'y 
adapter,  si  elle  veut  avoir  sa  place.  Dans 
cette  optique,  differents  axe®  d'fetude  et 
de  recherche  se  sont  developp6s  : 

.  Au  niveau  materiel  avec  I’emploi  de  pro- 
cesseurs  paralleles  ou  de  calculateura 
dedies  lA. 

.  Au  niveau  logiciel  avec  la  raod^lisation 
des  donnees,  le  raisonnement  temporal  et 
le  developpement  de  techniques  de  gestion 
du  "garbage  collector". 

En  se  limitant  a  I'aspect  logiciel,  il 
s'agit  de  maintenir  la  coh6rence  malgr6 
1' evolution  continue  des  faits.  Pour  la 
modelisation  des  donnees,  ceci  passe  par 
une  representation  temporelle  des  connais- 
sances  ;  les  faits  sont  dat6s  ou  ont  une 
validite  parametrable  en  fonction  du  temps. 
Pour  le  raisonnement,  on  cherche  A  exprimer 
des  relations  temporelles  qui  se  traduisent 
par  des  strategies  d ' ordonnanceraent  selon 
des  ^ch^ances  fix^es,  une  prise  en  compte 
des  delai>  dans  la  priority  d' execution  des 
regies  et  dans  le  degr6  de  validity  du 
raisonnement  final.  Ceci  dans  le  but  de 
prevoir  les  performances  au  moyen  d' appro¬ 
ximations  et  d' incertitudes  dans  le  raison¬ 
nement.  Le  gain  en  vitesse  d' execution  est 
souvent  lie  a  la  diminution  de  la  qualite 
du  raisonnement. 

ces  considerations  sur  le  raisonnement 
temporel  amfenent  naturellement  A  des  con¬ 
cepts  de  tAches  d'inf6rence.  Caci  se  tra- 
duit  par  des  blocs  de  rdgles  ininterruptl- 
bles  (les  rAgles  Atant  elles-mSmes  activa- 
bles  en  fonction  de  critAres  de  prioritA, 
de  temps  allouA  . . . )  et  par  un  gestlonnaire 
de  ces  tAches  qui  prend  en  compte  les 
interruptions  logiques,  les  attentes 
d'AvAnements,  les  prior itAs  ... 

La  motivation  centrale  de  I'Atuda  Atalt  de 
confronter  les  2  approchea  possibles  pour 


une  lA  embarquAe,  A  savoir  1 ' Interpretation 
(portage  direct  de  Prolog  sur  calculateur 
embarquA)  et  la  traduction  (compilation  de 
1' application  Prolog  en  un  langage  claosi- 
que),  en  regard  des  problAmes  dOcrits 
prAcOdemment . 


4.  METHODE  DE  DEVELOPPEMENT  POUR  L* ETUDE 


La  methodc  de  developpement  retenue  a 
pormis  d'obtenir  un  prototype  aussi  repr6- 
sentatif  que  possible  selon  differents 
axes  : 

.  Impiementer  un  systems  expert  refietant 
fideiement  I'aide  apportee  au  pilots 
par  une  determination  du  domaine  d' appli¬ 
cation,  un  rccueil  d'expertise  aussi 
complet  que  possible  et  une  validation 
par  les  experts. 

.  Mettre  en  evidence  les  contraintea  temps 
reel  sur  des  scenarios  de  mission  realis-* 
tes,  par  une  definition  appropriOs  du 
formalisms  de  representation  des  connals- 
sances  et  une  realisation  integrant  au 
maocimum  les  structures  particuliAres  A 
mettre  en  oeuvre  pour  I'achevemen^  d'un 
systeme  expert  temps  r6el. 

.  Apporter  des  elements  de  reponse  relatifs 
au  problems  de  1' integration  d'un  systems 
expert  dans  un  systems  embarque  global. 

Dans  le  soucis  d'attelndre  ces  trols 
objectifs,  1' etude  a  ete  decomposes  en 
differentes  phases  : 

1.  Specification  du  cadre  global  de  1* etude 

2.  Acquisition  de  1' expertise, 

3.  Definition  du  formalisme  de  representa¬ 
tion  de  la  connai usance, 

4.  generation  de  scenarios  de  mission, 

5.  Realisation  du  systems, 

6.  Validation  du  systeme, 

7.  Conclusions  sur  les  contraintea  liees  A 
1* implantation  d'un  systeme  expert  dans 
un  calculateur  embarque, 

e.  Conclusions  sur  I'lntegratlon  d'un 
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systeme  expert  dans  un  systeme  embarque. 


5.  ASPECTS  TEMPS  REEL  CRITIQUES  ABOROES 


DANS  L' ETUDE 


L' Ob jet  principal  de  1* etude  a  ete  d'appor- 
ter  des  elements  de  reponse  aux  dlfferents 
problemes  lies  aux  contralntes  d'embarqua- 
bilite  d'un  systeme  expert. 

Cette  etude  a  ^alement  permis  de  degager 
un  certain  nombre  d'axes  de  reflexion  pour 
I'avenir . 

Les  points  sensibles  que  I'on  deslrait 
apprehender  et  sur  lesquels  a  porte  1* ef¬ 
fort  sont  les  suivants  : 

1.  Volume  memoire  necessaire  pour  implemen- 
ter  1 'application  lA  sur  un  calculateur 
embarque. 

2.  Capacite  de  traitement  requise  pour  un 
calculateur  embarque  afln  de  respecter 
les  temps  de  reponse  imposes  par  1’ uti¬ 
lisation  operationnelle. 

3.  Examen  et  recensement  des  operations 
sensibles  ou  repetitives  qu'il  serait 
interessant  de  micro-programmer  afin 
d'accelerer  les  traitements  de  la  meme 
maniere  que  ce  qui  est  fait  actuellement 
pour  les  langages  classiques. 

4.  Necessite  d'utiliser,  sur  un  calculateur 
embarque,  un  Prolog  compile  ou  alors 
simplement  Interprete  dans  le  meme  but 
d'accelerer  les  traitements  et  de  tenir 
les  performances. 

5.  Compatlbllite  au  sein  d'un  systeme 

d' intelligence  artificielle  entre  les 
parties  purement  "inferentielles"  utili- 
sant  Prolog  et  celles  falsant  appel  a  de 
1 'algor ithmlque  et  utilisant  un  langage 
classique. 

6.  Caracteristiques  fonctionnelles  d'un 
moteur  d' inference  "adequat"  pour 

1 ' implementation  d'un  systAme  expert 
embarqtiable. 

7.  Structures  particuliAres  A  mettre  en 
oeuvre  au  point  de  vue  des  falts  et  des 
connaissances  pour  gArer  efflcacement 


des  informations  temporelles  et  parfois 
issues  de  plusleurs  sources. 

8.  Determination  des  caracteristiques  de 
1' interface  entre  le  systAme  expert 
et  d'autres  systAmes  avion  dAja  exls- 
tcints  pour  les  Achanges  d' informations. 

9.  HecessitA  de  concevoir  une  forme  de 
"moniteur"  pour  gArer  les  prioritAs 
entre  les  raisonnements .  Ceci  est  une 
consequence  directs  de  la  prise  en 
compte  d' informations  temporelles  par  un 
mecanisme  d’ interruption  sur  arrivAe 
d'AvAnements. 

10.  Adaptation  a  la  non-monotonie  des 
raisonnements  du  fait  de  la  manipulation 
d' informations  dont  la  validitA  est 
fonction  du  temps. 


6.  CONCLUSIONS  SUR  L' EMBARQUABILITE 


ET  PERSPECTIVES 


6.1  Conclusions  temps  reel 


6.1.1  Volume  memoire  et  capacitA  de 
traitement 

L'Atude  a  montrA  que  1' utilisation  des 
techniques  lA  Atait  tout  a  fait  envisagea- 
ble  dcins  le  cadre  d'une  application  temps 
reel. 

La  rAponse  aux  deux  principales  interroga¬ 
tions,  volume  mAmoire  et  capacitA  de 
traitement,  n'est  nAanmoins  pas  immAdiate. 
L'antagonisme  existeint  entre  la  rapiditA 
d'exAcution  et  le  volume  mAmoire  utilisA 
d'une  part,  et  les  temps  de  rAponse  et  la 
justesse  du  raisonnement  d' autre  part, 
imposent  de  faire  un  certain  nombre  de 
choix. 

Dans  le  domaine  de  la  gestion  des  alarmes, 
il  est  bien  Avident  que  le  pilote  ne  peut 
se  contenter  d'une  Avaluation  partielle 
de  I'Atat  des  systAmes  de  1 'avion  ;  la 
prior itA  dans  1' application  a  done  AtA 
donnAe  A  la  justesse  du  raisonnement. 

Kais  il  faut  veiller,  malgrA  tout,  A  faire 
parvenir  les  alcurmes  au  pilote  dans  des 
temps  raisonnables,  e'est-A-dire  compati- 


bles  avec  le  deroulement  reel  d'une  mission 
et  les  imperatifs  de  securite. 

Privilegier  les  aspects  completude  du 
raisonnement  et  temps  de  reponse  a  orientee 
1' etude  vers  une  approche  compilation  de 
1' application.  Cette  compilation  (des 
regies,  des  faits  et  du  moteur)  se  fait  en 
passant  par  un  langage  algor  ittunique 
classique  (Pascal  a  titre  d'essai). 
L'avantage  procure  par  cette  methode  est 
une  acceleration  des  temps  de  traitements 
(au  detriment  du  volume  memolre  genere). 

Dans  ces  conditions,  le  volume  memoire 
necessaire  a  l ' implementation  de  1 'appli¬ 
cation  dans  un  calculateur  embarque  clas¬ 
sique  DASSAULT  ELECTRONIQUE,  a  ete  estlme 
a  200  Koctets. 

Le  gain  en  temps  de  reponse  du  programme 
Pascal  par  rapport  a  la  maquette  Prolog  a 
quant  a  lul  ete  estime  a  10  environ,  ce  qui 
permet  de  satisfalre  I'objectif  fixe  au 
depart  (Ce  temps  de  reponse,  c'est-a-dire 
la  duree,  dans  une  version  operationnelle, 
entre  le  moment  oil  eirrlvent  les  evenements 
en  entrAe  du  systeme  et  celui  oil  on  obtient 
les  conclusions,  avait  ete  fixe  comme  infe- 
rleur  A  la  seconde). 

6.1.2  Traitements  microprogrammes 

La  validation  a  montre  une  forte  influen¬ 
ce  des  operateurs  lies  au  temps  dcuis  les 
regies  sur  le  temps  d' execution  de  celles- 
ci.  Ceci  est  du  au  calcul  de  I'heure  au 
moment  de  1 'application  de  la  regie.  Si 
dans  un  calculateur  clble  on  ne  dispose 
pas  d'une  horloge  eibsolue  (notion  de  temps 
vrai),  11  sera  souhaltable  de  micropro- 
grammer  la  sequence  de  calculs  elementaires 
destines  A  I'obtention  d'une  reference  de 
temps  absolue. 

6.1.3  Prolog  compile  ou  interprets 

Le  systAme  prototype  etait  initialement 
ImplementA  en  un  Prolog  InterprAte  (avant 
portage  de  1 'application  en  Pascal). 
L'avantage  de  cette  technique  est  la  grande 
dynamlque,  male  la  lenteur  qui  en  dAcoule 
va  A  centre  courant  d'une  utilisation  temps 
rAel. 

Dans  ces  conditions,  le  choix  d'un  Prolog 
compllA  paralt  d'autant  plus  nAcessalre 
que  le  calculateur  embarquA  est  d' archi¬ 


tecture  classique.  L'embarcpiabilitA 
exigerait  nAanmoins,  au  minimum,  la  dAfi- 
nltlon  et  la  rAalisation  d'un  moteur  dedlA 
A  la  machine  cible  et  "taillA  sur  mesure" 
en  Aliminant  les  fonctionnalltAs 
privilAgiant  1' aspect  convivial  du  produit 
dans  la  phase  de  dAveloppement . 

Le  problAme  de  rAcupAration  de  la  mAmoire 
vient  Agalement  confer ter  ce  choix  ;  cette 
opAration  dApend  de  la  nature  du  langage 
sulvant  qu'il  est  compilA  ou  interprAtA. 

II  est  prAf Arable  de  s'orienter  vers  des 
outils  "garbages  incrementaux”  A  temps  de 
dAclenchement  et  d' execution  fixAs  ou  des 
outils  "gcurbages  free"  qui  permettent  une 
bonne  maitrlse  du  temps. 

6.1.4  Moteur  d'infArence 

L'outil  utllisA  pour  modAliser  la  maquette 
(ENICAT  de  DASSAULT  ELECTRONIQUE)  se  prA- 
sente  comme  une  extension  de  Prolog  vers  un 
langage  orientA  objet. 

Le  dAveloppement  de  la  maquette  a  montrA 
que  de  nombreuses  fonctionnalltAs  offertes 
Petr  EMICAT,  A  la  fois  trAs  gAnArales  et 
trAs  pulssantes,  ne  trouvalent  qu'une 
utilisation  trAs  rAduite  pour  notre  appli¬ 
cation.  L'hypothAse  selon  laquelle  on 
embarque  le  systAme  dAveloppAe  dans  I'envi- 
ronnement  ENICAT  suppose  done  que  I'on  Ala- 
gue  ou  modifle  certains  de  ces  mAcanlsmes. 
En  revanche,  certaines  fonctionnalltAs 
pourraient  etre  enrichies  dans  le  cadre 
d’une  utilisation  temps  rAel,  en  particu- 
lier  les  logiques  et  opArateurs  liAs  au 
temps  dAveloppAs  pour  le  filtrage 
d '  alctrmes . 

6.1.5  Interruption  du  raisonnement  et 
non-monotonle 

Dans  1’ application,  la  prior itA  a  AtA  don- 
nAe  A  1' acquisition  d' informations  externes 
qui  se  fait  indApendamment  des  traitements. 
Plusieurs  scAnarios  critiques  en  arrlvAe 
d'AvAnements  ont  AtA  jouAs  et  ont  montrA  le 
bon  fonctionnement  des  mAccUilsmes  de  prise 
en  compte  des  nouvelles  donnAes. 

La  consAquence  de  ce  point  prAcis  est 
1' Invalidation  de  certaines  conclusions 
obtenues  par  le  systAme  expert  avant 
I'arrivAe  d’AvAnements  perturbateurs . 

La  validation  a  soullgnA  que  le  mAcanlsme 
de  mAmorisation  d'Atats  de  la  base  de  faits 
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affichait  une  certaine  faiblesse,  due  i  sa 
"brutalite"  d' application,  face  A  des  arri¬ 
ves  d'evenements  trop  fr^quentes  remettant 
en  cause  les  raisonnements  en  cours. 

6.2  Conclusions  sur  l ' integration  a  un  SNA 


Bn  conplement  des  caracteristiques  de  per- 
foriii2uices  du  calculateur  dedid  i  recevoir 
1' application  lA,  1 'etude  avait  pour  objec- 
tif  d'apporter  des  conclusions  quant  A 
1 ' integration  d'un  systeme  expert  dans  un 
Systeme  de  Navigation  et  d'Attaque  : 

.  degager  des  principes,  fonctions  et 
interfaces  qui  pourraient  etre  retenus 
pour  une  I A  embarquee  future, 

.  etudier  la  faisabilite  de  1 ' integration 
d'un  tel  systeme  expert  de  filtrage 
d'alarmes  dans  un  systeme  d'armes 
embcurque  deja  existant. 

La  taille  memoire  estimee  du  systeme  pro¬ 
totype  de  filtrage  d'alarmes  qui  a  servi 
de  support  a  notre  etude  est  de  200 
Koctets.  Les  calculateurs  embarques 
d'avions  de  type  Rafale  possedent  une 
capacite  memoire  de  quelques  N6ga-octets. 

L' integration  d'un  tel  systeme  expert  sur 
ce  type  d'avion  est  done  possible,  raais 
necessiterait  neanmoins  1 ' implantation 
d'un  calculateur  specifique,  au  niveau 
logiciel,  pour  les  applications  lA. 

En  general,  sur  les  avions  d'armes, 
la  tAche  cyclique  la  plus  lente  est 
activee  a  la  frequence  de  6,25  Hz.  La 
prise  en  compte  des  evenements  a  cette 
frequence  de  6,25  Hz  suppose  que  le 
systAme  expert  soit  capable  d'executer 
1' ensemble  des  raisonnements  et  d'abou- 
tir  A  un  diagnostic  en  moins  de  160  ms. 

Dans  le  cas  contraire,  le  probleme  de 
la  non-monotonie  et  done  de  la  remise 
en  cause  des  conclusions  intermediaires 
reste  entier  si  I'on  ne  redefinit  pas  les 
principes  d'activatlon  des  tAches. 

Le  systAme  expert  qui  a  Ate  dAveloppA 
pour  cette  Atude  ne  prend  en  compte  que 
des  informations  AlaborAes  d'Atats  ou 
de  pauuies  et  ne  traite  pas  les  informa¬ 
tions  primaires  issues  des  capteurs. 

Pour  qu'll  soit  IntAgrable  A  un  avion 
existant,  il  est  nAcessalre  de  disposer 
de  ces  informations  AlaborAes. 


L* integration  est  de  plus  facilitAe  si 
ces  informations  AlaborAes  existent  sous 
forme  numArique  et  si  elles  tramsltent  par 
un  bus. 

6.3  Perspectives  futures 


L'une  des  perspectives  suite  A  1' Atude  est 
d'approfondir  les  conclusions  relatives  a 
I'approche  traduction  du  systAme  expert  en 
un  langage  class ique. 

Le  point  central  de  cette  approche  est  le 
dAveloppement  du  traducteur.  La  premiAre 
phase  consiste  a  definir  un  formallsme  de 
reprAsentation  de  1 'expertise  permettant 
au  mieux  la  traduction.  Le  traducteur  est 
de  prAference  dAdle  a  un  type  d* application 
(la  synthAse  de  pannes)  ce  qui  permet  de 
clbler  le  formallsme  et  ainsi  d'optimiser 
la  traduction  vers  un  langage  classique, 
une  trop  grande  gAnAralitA  etant,  pour  le 
sujet  qui  nous  intAresse,  un  obstacle  a 
I'efficacitA. 

Les  avemtages  procures  par  cette  approche 
sont  de  plusieurs  ordres  : 

.  la  traduction  en  un  langage  classique 
(Ada  principalement )  permet  une  raeilleure 
maitrise  du  volume  memoire  et  des  temps 
d' execution, 

.  elle  permet  d'integrer  le  dAveloppement 
du  systAme  expert  a  la  chains  de  produc¬ 
tion  des  logiciels  de  systAmes  d'armes 
classiques,  ce  qui  permet  entre  autres 
toutes  les  Atapes  de  tests  et  de  valida¬ 
tion  que  la  criticitA  d'un  logiciel 
embarquA  impose, 

.  enfin,  le  portage  sur  un  calculateur 
embarquA  p>ermet  de  faire  Avoluer  le 
systAme  expert  dans  un  vAritable  environ- 
nement  temps  rAel,  sans  adaptation 
spAcifique. 

Les  autres  voles  de  recherche  dAgagAes  par 
cette  Atude  mArltent  Agalement  d'Atre 
considArAes.  Elles  concernent  prlnclpale- 
ment  le  dAveloppement  d'un  calculateur 
embarquable  dAdiA  A  I'lA,  le  portage  de 
Prolog  sur  calculateur  embarquA,  la  concep¬ 
tion  d'outils  de  base,  de  moteur  d'infAren- 
ce  temps  rAel,  ...  qui  font  I'objet 
d’autres  Atudes  A  DASSAULT  ELECTRONigUE. 
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SUMMARY 


Coobat  aircraft  of  the  2 let  Century  will 
have  to  be  increasingly  well  equipped  to 
counter  the  future  threat,  which  Itself 
will  have  becone  far  nore  potent.  This 
spiralling  system  complexity  will  result 
in  unacceptably  high  coclcpit  workloads 
unless  some  form  of  automation  is  provided 
to  aid  the  pilot.  UK  Industry  and 
Government  have  combined  to  form  a  Joint 
Venture  team  to  investigate  the  problem 
and  to  develop  a  Mission  Management  Aid 
which  will  assist  aircrew  throughout  the 
mission,  whatever  and  wherever  it  is.  The 
paper  outlines  some  of  the  problems  to  be 
overcome  and  suggests  the  major  functional 
areas  which  will  constitute  the  Mission 
Management  Aid .  ^  ^ 
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Artificial  Intelligence,  Automation, 
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At  the  end  of  this  Century,  Machine 
Intelligence  will  form  an  integral  part  of 
the  Man/Machine  combine  in  future  combat 
aircraft. 


Machine  Intelligence  will  be  used  to  fuse 
data  from  dissimilar  sources,  to  apply 
threat  values  to  the  fused  data  and  to 
optimise  a  flight  path  for  the  mission. 
This  will  relieve  the  pilot  of  many 
difficult  and  lengthy  cognitive  processes 
and  eneUaie  him  to  devote  considerably  more 
time  to  situational  awareness  and  tactics, 
particularly  when  under  stress. 

In  the  past,  it  has  been  possible  to 
absorb  periods  of  high  workload  by 
delaying  or  sharing  tasks  between  crew 
members.  Now  the  situation  has  been 
reached  where,  despite  automation,  the 

complexity  of  the  avionics  data  output  is 
at  such  a  level  that  the  crew  are 
Increasingly  less  able  to  cope  with  the 
workload  peaks.  This  situation 
is  exacerbated  with  the  tendency  of  combat 
aircraft  to  become  single  seat  designs, 
rurthermore,  the  density  and  increasing 
sophistication  of  enemy  surface-to-air 
weapons  greatly  adds  to  the  complexity  of 
the  task  which  confronts  the  pilot  on  an 
air-to-ground  strike  mission. 

Machine  Intelligence  in  the  form  of  the 
Mission  Management  Aid  (MMA)  will  provide 
a  solution  to  this  difficult  problM,  by 
providing  the  pilot  with  data,  processed 
to  fit  his  needs.  This  Aid  will  correlate 
data  from  many  sources  such  as  aircraft 
and  avionics  systeaw,  data  bases,  data 
links  etc  and  present  it  to  the  pilot  in 
an  easily  assimilable  way.  The  MMA  will 
fuse  the  data  frm  separate  sources  and 


sensors,  apply  confidence  factors  and 
threat  weightings  before  finally 
suggesting  optimum  flight  plans  which  will 
minimise  sortie  costs.  In  addition,  the 
MMA  will  monitor  and  evaluate  the  aircraft 
systems,  cue  the  pilot  to  the  most 
appropriate  action  and  generally  take  care 
of  the  normal  "house-keeping"  duties, 
performed  by  the  crew.  The  MMA  will  act 
as  an  advisor  to  the  pilot,  much  in  the 
same  way  that  a  navigator  does  now. 
(Further  details  of  the  MMA  can  be  found 
in  AGARD  Papers  by  Catford  and  Gray^  and 
Gibson  and  Garrett^) . 

If  required,  the  pilot  will  be  able  to 
interrogate  the  MMA  through  the  successive 
processing  stages,  back  to  the  raw  data. 
However,  this  facility  is  expected  to  be 
required  infrequently  as  the  pilot  gains 
confidence  with  the  MMA. 

For  the  full  potential  of  the  MMA  to  be 
realised,  a  number  of  areas  will  have  to 
be  very  carefully  studied,  problems 
identified  and  possible  solutions 
discussed.  For  example,  great  care  will 
have  to  be  taken  in  understanding  the 
pilots  information  requirements  and  in  the 
corresponding  presentation  of  MMA  data  in 
a  way  that  is  easily  assimilable  and 
reduces  his  workload.  On  a  broader  level, 
the  scope  of  the  MMA  requires  examination. 
Until  now,  it  has  concentrated  on  an 
European  conflict.  With  the  recent 
dramatic  Political  changes  in  Europe,  the 
MMA  will  need  to  be  flexible  to  function 
in  less  well  defined  operational  "out  of 
area"  scenarios  of  which  the  recent  Gulf 
War  is  an  example. 

Finally,  the  method  of  validating  the  MMA 
must  be  addressed.  The  advantages  of  the 
MMA  must  clearly  be  demonstrated  before  it 
will  be  accepted. 

Research  into  this  area  xs  well  underway 
and  is  being  undertaken  at  RAE 
Pamborough,  by  the  MMA  Joint  Venture 
Team,  consisting  of  BAe  (Military  Aircraft 
Ltd) ,  Smiths  Industries  Aerospace  (t 
Defence  Systems,  the  Royal  Aerospace 
Establishment,  Famborough  and  GEC- 
Marconi,  represented  by  GEC  Ferranti 
Defence  Systems  Ltd,  GEC  Avionics  Ltd  and 
GEC  Sensors  Ltd. 


It  could  be  argued  that  an  MMA  is 
unnecessary  as  the  aircrew  will  always 
make  up  for  the  shortcomings  of  the 
aircraft  systems.  Although  this  may  have 
been  true  in  the  past,  it  is  now  an 
increasingly  unreliable  method  of 
overcoming  the  problems  associated  with 
complex  systems. 
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It  is  difficult  to  measure  and  quantify 
workload,  particularly  in  a  real 
environment.  It  is  even  more  difficult  to 
assess  the  effects  of  battle  stress  upon 
crew  performance  and  then  to  estimate  if 
the  crew  has  spare  capacity  to  cope  with 
peaks  in  workload’. 

As  aircraft  and  their  systems  have  evolved 
over  the  years,  two  trends  have  become 
evident.  Firstly,  speeds  have  increased. 
Fig.  1  shows  the  almost  exponential  rise 
in  combat  aircraft  top  speeds.  Secondly, 
as  Fig.  2  shows,  the  number  of  instruments 
to  be  monitored  in  the  cockpit  has  also 
Increased  dramatically.  Even  though  this 
trend  appears  to  have  been  arrested  in  the 
1970 's  with  the  introduction  of  CRT's  in 
the  cockpit,  the  quantity  of  information 
to  be  monitored  actually  increased  with 
the  advent  of  multi-function  electronic 
displays. 


Maximum  Speed 
in  M.P.H 


Fig  1 .  MAXIMUM  SPEED  OF  COMBAT 
AIRCRAFT  WITH  IN-SERVICE  DATE 


Figure  3  shows  the  steady  increase  in  the 
numSaer  of  systems  present  in  fighter 
aircraft  from  Hurricane  to  ri8.  Not  only 
has  the  number  of  systems  risen  but  the 
complexity  of  the  systems  has  also 
increased  considerably. 

Thus,  the  combat  crew  of  today  fly  faster 
and  lower,  but  have  less  time  in  which  to 
monitor  and  control  a  greater  number  of 
systems  whidb  are  themselves  more  complex 
than  before.  These  factors  all  contribute 
to  an  unacceptably  high  workload. 


In  the  past  it  has  been  assumed  that  when 
overloaded  with  tasks,  the  crew  will  shed 
the  less  important  tasks  to  enable  the 
essential  tasks  to  be  concentrated  upon. 


Year  in  Service 

Fig  3.  GROWTH  IN  COMBAT  AIRCRAFT  SYSTEMS  WITH  YEAR  IN  SERVICE 


This  does  in  fact  usually  occur,  but  it  is 
not  generally  realised  that  the  shed  tasks 
often  require  a  great  deal  of  effort  to  be 
brought  back  on  line  after  the  workload 
peak  has  been  passed.  There  is,  in  fact, 
a  workload  hysteresis  loop  around  which 
the  crew  have  to  go.  Figure  4  depicts  in 
general  terms,  the  succession  of  events. 

As  workload  increases,  the  crew 
performance  climbs  to  a  maximum.  After 
the  maximum  is  reached,  tasks  are  shed 
rapidly,  leaving  only  the  primary  task  and 
the  overall  performance  drops  to  a  much 
lower  level.  The  shed  tasks  cannot  be 
immediately  absorbed  again  but  have  to 
be  steadily  built  up  from  a  low  overall 
level  of  performance. 

Some  form  of  automation  or  assistance  for 
the  crew  is  clearly  required  to  prevent 
the  maximum  workload  being  exceeded. 

In  the  past,  attempts  have  been  made  to  do 
this  by  automating  some  of  the  crew's 
tasks.  Often,  the  tasks  that  the  man  can 
do  well  have  been  automated,  (possibly 
because  they  are  understood,  can  be 
defined  and  therefore  duplicated  by 
machines) .  The  man  then  has  been  left  to 
do  the  tasks  %diich  he  is  not  necessarily 
good  at,  such  as  monitoring  but  which  a 
machine  might  do  far  better  than  the  man. 
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This  has  resulted  in  a  less  than 
satisfactory  inefficient  nan/machlne 
systeB  which  has  sonetimes  produced  a 
higher  crew  workload  than  when  not 
automated^.  In  a  recent  HkSA  study,  over 
half  of  200  Boeing  757  pilots  said  that 
they  felt  automation  actually  increases 
workload.  Nearly  half  of  the  pilots  were 
concerned  about  the  possible  loss  of 
flying  skills  when  there  is  too  much 


Communications  Systems,  Terrain  and 
Tactical  Dat2d>ases  and  Pilot  Input.  The 
data  is  processed  in  two  stages  into  an 
alpha  scene  (a  model  of  the  outside  world 
with  associated  confidence  levels) . 

The  first  stage  is  the  correlation  of 
tracks  into  positions  and  velocities. 

This  involves  the  alignment  of  data  with 
different  accuracies,  temporal  and  special 
reference  frames  and  the  stibseguent 
association  of  tracks  into  multiple 
resolved  tracks  with  confidence  levels. 

The  second  stage  is  attribute  fusion,  the 
identification  of  objects  using  Sensor 
data  in  the  form  of  RADAR  or  IR 
signatures.  The  output  from  Fusion  is  a 
set  of  objects  with  their  positions, 
velocities  and  Identities,  where  eash 
quantity  has  an  associated  confidence 
level . 

The  alpha  scene  produced  by  Sensor  Fusion 
is  fed  into  the  Situation  Assessment 
function.  Situation  Assessment  is  a 
multistage  filtering  process.  Firstly, 
objects  identified  as  friendly  are 
filtered  out  of  the  alpha  scene  for 
separate  processing,  because,  although 
they  do  not  constitute  a  threat,  their 
presence  my  influence  the  overall 
assessment  of  the  threat  environment.  The 
remaining  unknown  and  hostile  objects  are 
assessed  using  numerical,  behavioural, 
operational  and  associated  intelligence  to 
form  a  model  of  the  integrated  threat 
environment . 


Fig  4.  THE  WORKLOAD  HYSTERESIS  CURVE 


automation.  Some  pilots  thought  that 
their  hand/feet/eye  co-ordination  is 
faster  than  their  programming  and 
monitoring  capabilities. 

Thus,  it  is  essential  that  any  assistance 
provided  to  the  pilot,  in  terms  of 
automation  or  aids,  concentrate  on  the 
activities  which  man  is  not  good  at  and 
leave  him  the  tasks  at  which  he  is 
superior  to  the  machine.  This  is  the 
philosophy  which  has  been  adopted  for  the 
Mission  Management  Aid. 


1^_THE  MISSION  MANAGEMENT  AID 


The  objects/ systems  are  then  prioritised, 
with  those  adjudged  to  be  the  most 
important  (threatening,  vulnerable  or 
supportive)  filtered  off  to  make  up  the 
beta  scene. 

The  output  beta  scene  comprises  a  set  of 
objects  containing,  position,  velocity, 
identity,  status  and  threat  value 
information,  the  beta  scene  is  the 
primary  input  to  the  third  MMA  Core 
Function,  the  Planner. 

The  Planner  constructs  tactical  plans 
(gammas)  including  a  gamma*  option,  that 
is  perceived  to  be  the  most  favourable. 
Its  plans  are  based  on  the  mission 
objectives  and  constraints,  the  current 
situation  (beta  scene)  and  available 
resources,  such  as  fuel,  weapons, 
countermeasures  and  supporting  aircraft. 


The  primary  aims  of  a  Mission  Management 
Aid  are  to  advise  the  aircrew  such  that 
survivability  is  increased,  particularly 
in  complex  high  threat  or  unfamiliar 
environments,  and  that  workload  is  reduced 
to  allow  the  aircrew  to  concentrate  on  the 
tasks  at  which  the  man  is  superior  to  the 
machine,  such  as  inductive  reasoning  based 
on  experience. 

To  achieve  these  aims,  the  MMA  has  been 
broken  down  into  a  small  number  of 
component  parts,  or  MMA  Core  Functions, 
which  are  Shown  in  Figure  5. 

The  first  core  function  in  the  MMA  is  that 
of 


Major  functional  blocks  within  the  Planner 
are;- 

Route  Options 

Construction  of  coarse  tactical  plans 
in  terms  of  3  dimensional  waypoints. 

Velocity  Potions 

Velocity  selection  and  modification 
of  the  planned  route  to  ensure  that 
the  mission  fuel  and  tine  constraints 
can  be  met. 

Attack  and  Countermeasure  Options 

Based  on  the  mission  objectives, 
values  of  potential  targets  and 
threats  and  the  current  status  of  the 


Sensor  Fusion 

Sensor  Fusion  takes  in  information  from 
the  aircraft's  Sensor  Suite, 
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aircraft's  weapons  and 
countermeasures,  this  function 
provides  options  for  an 
attack/defence  strategy  to  be 
incorporated  into  the  gamma. 

Situation  Prediction 

Evaluation  of  the  utility  of  a  gamma, 
talcing  account  of  the  expected  threat 
response  along  the  planned  route, 
given  the  effects  of  terrain 
screening,  planned  countermeasure 
usage  and  the  value  of  any  targets 
encountered. 

Tactical  Routeino;- 

Forms  a  detailed  plan  for  the 
•immediate  future*  requirements  based 
on  constraints  derived  from  the 
gamma. 

The  final  gamma  output  contains  several 
levels  of  data  covering  the  employment  of 
weapons  and  countermeasures  velocity 
requirements,  waypoints,  detailed  tactical 
route  and  anticipated  hostile  weapon 
release  points. 

In  addition  to  this  primary  thread  of 
operation,  the  three  Core  Functions 
interact  with  a  number  of  management 
functions.  These  managers  are  basically 
resource  schedulers  and  housekeepers  for 
the  aircraft  systems  most  closely 
connected  with  the  Core  MMA. 

The  Sensor  Manager 

Process  requests  from  the  Core  MMk 
for  extra  information,  checks  the 
possible  consequences  of  using  the 
appropriate  sensor  and  finally  issues 
commands  to  the  affected  sensors. 

Thg .  Havlgation..  Kanaggr;  - 

Performs  terrain  referenced 
navigation,  terrain-following 
avoidance  utilising  information 
generated  by  the  Core  MMA  Functions. 

The  Communications  Manager; - 

Controls  the  Communication  Systems 
ensuring  that  information  is 
transmitted  in  a  timely  manner  when 
there  is  a  high  probability  of 
effective  reception  and  a  low 
probability  of  intercept. 


The  Health  t  S^tus  Manager 

Monitors  the  Health  and  Status 
information  provided  by  the  aircraft 
systems.  In  the  case  of  health 
reports,  this  will  involve 
prioritisation  of  data  dependent  on 
urgency/criticality  of  the  report, 
based  on  the  current  phase  of  the 
mission  and  in  the  light  of  other 
reports. 

This  information  along  with  the 
general  status  data  is  made  available 
to  all  relevant  Core  MMA  Functions 
and  for  possible  presentation  to  the 
Pilot. 

It  should  be  stressed  that  the  MMA  Core 
Functions  and  other  functions  are  dynamic 
and  are  constantly  updating  the  alpha, 
beta  and  gamma  scenes  as  the  aircraft 
progresses  through  the  mission.  Clearly, 
the  interaction  between  the  MMA  and  pilot 
is  potentially  very  complex. 

For  this  interaction  to  be  effective,  the 
Pilot  Interface  Manager  and  Man/Machine 
Interface  (MMI)  needs  to  be  very  carefully 
designed.  The  Aircrew  must  be  provided 
with  the  information  that  is  required  at 
the  relevant  time.  They  must  not  be 
overwhelmed  with  information,  yet  they 
must  be  given  the  opportunity  to 
interrogate  the  core  functions  as  far  back 
as  the  raw  sensor  data.  As  the  MMA 
evolves  and  is  improved,  the  aircrew  will 
Increase  their  confidence  in  it  and  will 
feel  less  need  to  check  back  on  the 
earlier  processing  stages.  Much  of  the 
MMI  design  will  evolve  through  simulation 
and  feedback  from  aircrew  participating  in 
simulator  experiments. 

There  is  always  the  danger  that  because  we 
have  the  technology  and  software  to 
provide  a  complex  sophisticated  solution 
to  a  problem  it  must  be  adopted  despite  a 
cheaper  and  simpler  solution  being 
available.  Frequently  this  has  been  the 
case  and  the  user  has  been  saddled  with  an 
expensive  piece  of  equipment  which  is 
difficult  to  use,  resulting  in  a  very  low 
overall  system  performance.  The  MMA  must 
not  fall  into  this  trap. 


pilots  beta  scene 


Fig  5.  MMA  CORE  FUNCTIONS  and  INTERFACES 
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There  always  will  be  a  fundanental 
difference  between  the  way  the  crew 
Interact  with  each  other  and  the  way  crew 
will  Interact  with  an  MHA. 

Currently,  a  great  deal  of  infomation  is 
exchanged  between  crew  meiabers  over  the 
intercoe.  systen.  The  crew  rely  on  a 
large  vocabulary  which  includes  a  sub-set 
of  technical  terms  and  jargon  specific  to 
the  mission.  (See  Annex  of  Air-to-Alr 
combat  transcript  from  intercom) .  It  also 
relies  upon  a  personal  or  social  knowledge 
of  each  other  which  is  used  to  build  up 
team  confidence.  It  is  difficult  to 
imagine  joining  an  MMA  in  the  mess  bar 
after  a  difficult  sortie  to  discuss  how 
the  next  mission  should  be  planned! 

Despite  the  generally  poor  quality  of 
intercom,  systems,  some  Intonation 
signifying  urgency,  etc,  accompanies 
speech  which  provides  further  information, 
to  the  recipient. 

In  the  case  of  side-by-side  seating,  as  in 
Support  Helicopters,  much  Information  is 
obtained  from  body  language,  head  and  arm 
movements  (This  has  been  observed 
frequently  by  the  author  but  never 
quantified) .’ 

When  relying  on  an  MMA  many  of  these  cues 
will  be  absent  and  therefore  the  MMA 
performance  will  have  to  provide 
additional  assistance  to  compensate  for 
these  shortcomings.  (It  could  be  argued 
that  eventually  "intelligent"  Direct  Voice 
Input  and  Synthesised  Speech  will  have 
large  vocabularies  with  100%  recognition 
rates  and  provide  accurate  intonation 
related  to  the  situation  but  this,  the 
author  believes,  will  be  beyond  the  MMA's 
timeframe) . 


Until  recently,  most  aircraft  systems 
tended  to  be  Installed  as  separate  items 
with  little  attention  paid  to  their 
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integration  as  a  complete  package.  There 
is  now  a  move  towards  true  integration  of 
avionics  in  the  form  of  Advanced  Avionics 
Architectures  and  Pac)caging  (A3P) . 

The  primary  aims  of  A3P  are  to  overcome 
the  problems  of  Inadequate  system 
Integration,  as  mentioned  above,  and  to 
reduce  the  long  term  costs  of  ownership  of 
an  aircraft  and  its  systems. 

The  timescales  and  the  objectives  of  the 
MMA  and  A3P  progreunmes  have  much  in 
common.  Some  consideration  should  be  given 
therefore  to  ensure  that  both  programmes 
are  in  phase  with  each  other  and  that 
there  is  a  minimum  of  duplication  of 
effort.  Currently,  the  MMA  is  seen  to  fit 
comfortably  within  the  A3P  framework. 


Machine  Intelligence  in  the  form  of  a 
Mission  Management  Aid  will  be  essential 
to  enable  the  crew  of  combat  aircraft  to 
perform  effectively  in  the  21st  Century. 

The  MMA,  as  envisaged  at  present,  will 
fuse  the  data  from  many  sources,  apply  an 
"intelligent"  assessment  of  the  threats  to 
provide  an  awareness  of  the  situation  and 
advise  the  aircrew  of  the  best  course  of 
action  to  minimise  threat,  within  the 
boundaries  set  by  the  mission  constraints, 
e.g.  fuel,  expendables,  flight  envelope 
etc. 

Thus,  it  will  reduce  workload  and  allow 
the  crew  to  concentrate  on  the  high  level 
decision  making,  confident  that  the  MMA  is 
performing  the  "housekeeping"  duties  of 
system  monitoring,  fuel  state  calculation 
and  lower  level  decision  making.  It  will 
advise  the  crew  of  changes  of  route  or 
manoeuvre  which  are  caused  by  unexpected 
events  which  can  occur  at  any  time  during 
the  mission. 

Without  an  MMA  to  assist  them,  the  crew  of 
the  21st  Century  combat  aircraft  will, 
with  increasing  frequency,  be  overwhelmed 
by  workload  problems  and  at  a  severe 
disadvantage  with  those  combat  aircraft 
and  crews  who  have  artificial  intelligence 
to  assist  them. 
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TRANSCRIPT  OF  COCKPIT  COHVERSATIQH  3EXSEEtl 
OWE  F4  CREW  DURING  A  2  F4  VS  2  F16  VS  2  E5 ■ EMGASEMENT 
AT  AM  AIR  COMBAT  MANOEOVERING  RANGE 


ARMAMENT:  F4  -  Radarguided/IR  Missiles  +  Guns; 

P5  -  IR  Missiles  +  Guns  ;  F16  -  IR  Missiles  + 

Guns 

INITIALISATION:  Each  pair  at  the  point  of  an  equidistant 

triangle  -  approx  30  nm  separation  -  live 
when  pass  within  1.5  miles  of  centre. 

CALL-SIGN:  Zippy 


TifflgfsJ  Eiiat  Na.vigat.9E  EtQ/Qthar 

(Heading, 
Range  etc) 
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20 


40 


Looking  for  bogeys 
...descent  now, 
unloading 

Fight’s  on  Mike 
OK 

Check  we’ve  got 
Sparrow, 

Master  Arm 


Ready 


Check 
Check  live 


Ready  we  have 
CWs  on  today 


Affirmative 


no  discrete  contact 


on  the  nose,  18 

9000  ft,  600  kts 

No  discrete  contact 
yet 


0,3,0  -  12 
1,2,0  -  17 
2,1,0  -  14 

0,3,0  -  8 


1,2,0  -  16 
2,1,0  -  11 

0,3,0  -  5 

1,2,0  -  14 


. . .burners  coming 
out 

High  on  the  nose,  12. 
Pair  of  bogeys  heading 
towards,  10  miles  at 
30,000 


Roger,  8  miles  closing, 
..slightly  left, 
fighting  wing 

75  7  miles 

bogeys  are  50  degrees 
high 


Just  about  on  top,  now 

85  Nothing  seen 

_ 7  miles,  we're  live, 

we’re  live 
. . . .we’re  live 

_ keep  on  trucking  Hike 

we've  got  1  Mach,  Mach  1 
not  enough 

Scopes  clear  of  bogeys 

100  Roger 

10,000  ft  we’ve  got  Mach 
1.05,  not  enough 


7.9 


All 
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120 


135 


150 


160 


170 


180 


190 

that 


200 


220 


He's  breaking  port 

(MX  firing  tone) 

OK,  fire  missile,  fire 
missile,  snap  rt  190 

(MX  firing  tone) 

Take  a  Fox  1,  take  a  Fox  1 

190  now 


GO  Sidewinder,  after  it. 
...Ol lie's  coming  stbd 
I  think,  I'm  not  sure 

OK  he  IS  confirmed 

OK,  come  stbd  then,  20 
right,  range  5. 

20  rt,  range  5,  pulling 
.  .  up,  look  high,  look  hi 

Looking  up  Look  hi 

no,  not  a  thing 

Look  20  rt,  range  3,  20 
^ .  right,  range  3  high 

Nothing  seen 

20  right  range  3 

Nothing  Seen 

Well,  he'll  be  going  over 
the  top  shortly,  we're 
going  to  bug-out  base  ht 

OK,  we're  bugging 
out  now. .... 


Roger,  Hawkeye's 
bugging  out  South 


(Mx  firing  tone) 


OK 

(Mx  firing  tone) 


Hawkeye. . . . 

Missile  on 
Hawkeye 


Keep  going,  keep  going, 
don't  break 


Fight's  out  let,  long 
range 

Derek, 


I'll  keep  going 
holding  base  ht 


Reheat  cut 


Vector  for  home 


Keep  going 


Roger 


L-B,  Fox  2 
. . hdg  2,2,0 
good  kill . . 


OK  that ' s  good 


Transmit 


That's  a  negative  kill 
from  L-B,  we're  2 
miles  in  behind 


port 

Roger 


OK,  come  port 
Make  your  hdg  0,6,0 

Derek 
(Maintain 
hdg  for 
bugging 


AlO 


Knock-it- 


% 


-it-off . 
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Discussion 


1.  D.  Bosnian,  Netherlands 

Is  it  possible  to  quote  a  ‘typical’’  (statistical  average?)  time 
duration  or  constant  associated  with  the  workload/ 
performance  hysteresis  loop?  How  many  minutes  for  skills 
acquired  in  over-learned  training  for  example? 

Author: 

The  hysteresis  loop  shown  is  only  a  concept  at  this  state.  I  am 
trying  to  accumulate  data  to  help  to  quantify  the  shape  of  the 
curve  more  accurately.  Any  data  supporting  the  hysteresis 
hypothesis  will  be  welcome. 

2.  P.  Bouchard,  United  States 

Please  describe  the  example  of  pilot  overload  in  the  Gulf 
War  which  you  cited  when  briefing  your  hysteresis  loop  of 
pilot  effectiveness  versus  workload. 

Author: 

According  to  Flight  International,  a  Tornado  and  crew  were 
downed  when  the  crew  became  engrossed  in  a  guided 
weapon  delivery  —  and  ignored  electronic  warnings  of  two 
approaching  missiles. 

3.  G.H.  Hunt,  United  Kingdom 

The  constraints  are  put  into  route-planning  in  order  to 
minimize  the  difficulty  of  the  flying  task  and  hence  reduce 
the  pilot  workload  ? 


Author: 

No  constraints  are  placed  on  the  pilot’s  flying  task.  Should 
the  pilot  deviate  from  the  MMA  recommended  path,  the 
MMA  will  reassess  the  threat  at  the  new  point  and  suggest  a 
new  optimal  route.  However,  the  aircraft  flight  path  is 
calculated  taking  account  of  normal  maneuver  limits  which 
depend  upion  fuel  and  weapon  load  etc.  and  the  MMA’s 
route  calculations  to  include  a  first  order  ride  comfort 
function. 

4.  George  Chapman,  United  States 
What  techniques  does  your  system  use  to  carry  out  your 
optimization  of  resources?  Does  you  method  allow  changes 
in  the  objective-function  (cost  function)? 

Author: 

A  pragmatic  approach  which  models  a  human  planning 
paradigm  is  used.  The  basic  principle  is  to  start  with  one  (or 
more)  simple  plans;  to  analyse  what  is  wrong  with  a  plan,  and 
thus  decide  how  best  to  improve  it.  A  Suitable  Modification 
method  is  applied  to  the  plan  which  is  then  evaluated. 
Selection  of  a  plan  for  analysis  is  dependent  on  its  cost  and 
number  of  descendant  plans.  This  approach  attempts  to  deal 
with  both  combinational  explosion  of  options  and  a  real¬ 
time  requirement  to  always  have  a  complete  plan  available. 
The  resolution  of  the  cos  :  function  varies  with  depth  of 
search  and  in  the  mission  planner.  In  both  mission  planner 
and  tactical  routing  functions,  the  first  function  to  run 
analyses  the  search  problem  to  be  solved  as  well  as  the 
aircraft  status  (e.g.  mission  phase,  fuel  level,  etc.)  and  sets  up 
the  various  weighting  factors  accordingly. 


1 


COMPONENT  PART  NOTICE 


This  paper  is  a  C0NP0I€NT  PART  of  the  following  COMPILATION  report: 

(TITLE):  jnachth^ 

AMSjpac^A  £tMrfk’An/(^  £tf^hu>ts  H-tld  Ljshayi j  a/) 

/3-/^»  daj>is 

_ _ AA*  a  r  iff/mc^haidf4t0S  auy) 

(SOURCE):  ^  ir^  «  y/ 

A^rchauhcAJ  /f^S^aye.A  omJ  b^u»ttfmfiif.Aftuil\y'’SaM>  -Se/s^ 

To  ORDER  THE  COftf^LETE  COMPILATION  REPORT  USE  AlyH3.*l20XS  CFi^-^c^) 


The  component  PART  is  provided  here  to  allow  users  access  to  individually 

AUTHORED  SECTIONS  OF  PROCEEDINGS^  ANNALS>  SYMPOSIA,  ETC*  HOWEVER,  THE 

COMPONENT  SHOULD  be  considered  within  the  context  of  the  overall  compilation 

REPORT  and  NOT  AS  A  STAND-ALM£  TECHNICAL  REPORT* 


The  following  COMPONENT  PART  numbers  comprise  the  COMPILATION  report: 

_.AD#:  Tlll£t._„ _ _ — - - - 


AV- 

/^D-PooCs  -2.^2. 


r;Tis 

CP.-'  'J 

[■!  i 

*3 

r  i 

-J  •• 

'  1 

.  lu.-.t 

By 

1 

i 

Olat  lb 

•  tic.  ■  / 

1 

AV,;li 

O 

O 

-  X 

r.’ 

r, 

_ 

Avdil  c 

'■■■-'J  lor 

Dist 

<C 

Cidl 

XJ 

|yA-i 
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CODE  505 

,  WARMINSTER,  PA  18974-5000  USA 


the  Robotic  Aircraft 
s  IcDula  t  Ion 
Air  Development 

(A.  It  Is  extracted 

f  a  three  year 


ABSTRACT 

This  report  describes 
Sensor  Platform  (RASP) 
developed  at  the  Naval 
Center  In  Warminster, 
from  the  final  report 

research  effort  Into  tbe  architectures 
needed  to  develop  realftime  Artificial 
Intelligence  (AI)  techniques  for 
autonomous  aircraft.  A  hardware  and 
associated  software  architecture  has  been 
developed  to  use  on-board  sensor 
Information  for  high  level  AI  decision 
making.  The  decisions  then  direct  the 
flight  path  of  the  aircraft  and  camera 
glfflbal  through  complex  environments.  This 
project  has  produced  a  system  architecture 
that  breaks  the  bottleneck  of  flyable 
real-time  AI  control  systems.  The  work 
has  transitioned  Into  three  new  efforts;  a 
flight  test  effort  for  the  Unmanned  Air 
Vehicle  Joint  Program  Office,  an 
investigation  Into  use  of  SOAR  for  novel 
systems  of  sensors  and  platforms  such  as 
the  Tactical  Imaging  System,  and  a  study 
of  applying  this  technology  to  manned 
platforms  to  assist  human  operators. 


MISSION 

The  selected  mission  begins  with  a  search 
of  an  area  of  ocean,  scanning  for  ships. 
When  a  ship  is  sighted  the  aircraft  must 
change  its  course  and  aim  the  camera. 
Avoiding  danger  In  this  environment 
requires  the  aircraft  to  maintain  a  safe 
stand-off  distance  from  all  ships.  In 
addition,  since  most  eyes  on  a  ship  point 
forward,  the  safer  path  of  approach  Is 
aroulfd  the  stern.  The  payoff  of  the 
replanned  maneuvers  Is  one  optimum  picture 
of  the  ship,  off  her  beam  (side)  and 
nearly  filling  the  field  of  view.  Losing 
interest  after  the  best  beam  shot,  the 
aircraft  will  carefully  maneuver  away  and 
continue  the  search  pattern  for  other 
ships . 


It  was  realized  early  In  the  project  that 
a  hyper-br llllant  ’*R2-D2*'  was  beyond  the 
scope  of  current  technology*  Other 
projects  such  as  DARPA's  ALV  (Advanced 
Land  Vehicle)  and  Pilots  Associate,  and 
the  Air  Force/DARPA  RAV  (Robotic  Air 
Vehicle)  had  taken  very  ambitious 
approaches  and  were  not  performing  as  well 
as  expected.  These  AI  systems  run  on  LISP 
language  processors,  requiring  rooms  full 
of  computer  hardware,  and  not  performing 
in  real-time.  Instead  we  chose  to 
investigate  a  system  capable  of  providing 
sensor  driven  artificial  intelligence 


autonomous  control  using  more  efficient 
programming  languages  and  processors. 

The  first  year  of  the  effort  was  spent 
researching  the  prior  art,  studying  all 
known  published  autonomous  vehicle  work. 
There  Is  a  continuous  range  of  vehicle 
autonomy  ranging  from  tele-operated  with  a 
remote  linked  human  making  control 
decisions,  to  completely  autonomous  or 
robotic  with  no  human  Involved  after 
launch.  We  were  interested  In  the 
completely  robotic  vehicles  because  use  of 
the  system  by  the  Navy  often  requires 
radio  silence.  The  robotic  aircraft 
available  or  under  development  at  this 
time  can  be  grouped  into  broad  categories 
by  their  mission.  The  most  ambitious 
systems  perform  an  overland  attack 
mission,  a  very  complex  scenario  requiring 
computing  resources  at  the  extreme  limit 
of  current  technology.  The  other  major 
branch  of  systems  Is  Intended  for 
surveillance  missions.  The  ''smart*' 
systems  currently  available  are  only 
waypoint  flyers  with  no  autonomous 
replanning  capability.  The  developing 
systems  using  AI  techniques  are  for  the 
long  duration,  high  altitude  platforms 
that  require  AI  logic  for  recognition  of 
tactics  and  long  term  decision 
Implications.  Maneuvering  of  the  aircraft 
in  these  systems  is  used  to  achieve  long 
t  erm  goal s . 

The  decision  was  made  to  develop  a  near- 
term  system  that  provides  a  very  definite 
Improvement  in  the  operation  of  short  to 
medium  range  reconnaissance  aircraft  at 
medium  to  low  altitudes.  The  charge- 
coupled  diode  (CCD)  imaging  camera  was 
chosen  as  the  primary  sensor  because  it  is 
small,  passive  and  inexpensive,  yet  can 
provide  unparalleled  evidence  of  ship 
identity  and  disposition.  The  low  and 
slow  aircraft  flight  allows  simple  cameras 
and  lenses  to  achieve  good  Images  of 
ships.  The  slow  flight  also  gives  the 
computer  time  to  make  decisions  and  allows 
the  aircraft  to  turn  with  a  small  radius. 
RASP  was  restricted  to  over  water  missions 
because  the  Images  and  scenarios  are 
simpler  than  overland  missions,  yet  the 
collected  data  Is  very  useful  to  the  Navy. 
The  mission  was  then  defined  by  a  detailed 
analysis  of  flight  phases.  Aircraft 
piloting  navigation  modes  and  camera 
control  modes  were  defined  for  each  flight 
phase. 
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The  Sensor  Driven  Airborne  Replanner  was 
developed  to  link  sensor  signal  processing 
Co  traditional  control  systems.  This  sort 
of  link  Is  performed  by  alr-co-alr 
missiles  when  closing  on  a  target.  The 
difference  here  Is  that  the  RASP  Is 
required  Co  perform  target-related 
maneuvers  that  are  much  more  cognitively 
complex  chan  a  missile  end-game.  This 
justified  Che  artificial  Intelligence  link 
between  the  sensor  Information  database 
and  Che  control  systems,  (see  Flg.l) 

SPAR 

SOAR  accepts  the  current  camera  azimuth, 
elevation,  and  focal  length  from  the 
Camera  System,  the  latitude,  longitude, 
and  length  of  the  ship  that  Is  currently 
In  the  field  of  view  (If  any)  from  the 
Vision  System,  with  the  current  RASP 
latitude,  longitude,  and  altitude,  roll, 
pitch,  and  yaw  from  the  Navigation 
Sensors.  Based  upon  that  Information,  and 
upon  data  that  has  been  saved  from 
previous  cycles.  It  chooses  a  state  (see 
Section  2)  and  Its  associated  arguments. 
Then,  based  upon  that  state.  It  generates 
commands  to  (1)  the  Autopilot,  specifying 
the  desired  turn  rate,  (2)  the  Camera 
System  specifying  camera  glmbal  rates  and 
focal  length  commands,  and  (3)  the 
transmitter,  specifying  whether  or  not  It 
should  transmit.  When  In  PHOTO  state, 

SOAR  also  provides  Che  transmitter  with 
the  length,  speed,  heading,  and  position 
of  Che  ship  that  Is  being  Imaged. 

SOAR  must  work  Intelligently  and  In  real 
time.  Yet  It  must  be  small,  light,  and 
Inexpensive  Co  be  of  practical  use  In 
unmanned  autonomous  vehicles  (UAVs). 

Thus,  exhaustive  research  on 
hardware/software  architectures  for  real¬ 
time  AI  was  conducted.  The  selection  of 
Che  software  architecture  of  SOAR,  the 
programming  language  In  which  It  Is 
written,  and  the  processor  on  which  It 
will  be  executed  was  made  for  this 
research.  This  section  describes  those 
design  decisions. 

The  Software  Architecture 
SOAR  uses  the  Al  "rule-based"  software 
architecture.  This  architecture  was 
selected  because  It  accommodates  change 
yet  provides  a  very  clear  mental  model  of 
Che  logic  process.  That  flexibility  and 
clarity  proved  to  be  extremely  valuable 
during  Che  evolution  of  SOAR. 

SDAR's  Inference  engine  uses  "forward 
chaining".  Forward  chaining  means  Che 
system  works  with  facts  to  make 
conclusions.  (Backward  chaining  systems 
try  to  prove  tentative  conclusions  based 
on  the  facts.)  The  match  phase 
Inefficiency  found  In  many  forward 
chaining  rule-based  systems  Is  avoided  In 
SOAR  by  rule  priority  processing  and  by 
Che  high  efficiency  of  the  Inference 
engine  code.  Also  the  rule  base  was 
minimized  to  avoid  match  phase  time 
problems . 

The  forward  chaining  was  selected 
primarily  because  backward  chaining  la 
Inappropriate  for  SOAR.  SDAR's  data  base 
la  very  volatile;  the  locations  of  shlpa 
and  the  location  of  RASP  Itself  change 
constantly  In  real-time.  Thus  the 
contents  of  the  data  base  constantly 


change  In  real-time.  The  database  Is  so 
volatile  that  It  would  be  Impossible  for 
SDAR  to  complete  non-trlvlal  backward 
chains  before  the  contents  of  the  database 
changed.  When  the  contents  of  the 
database  change  during  the  creation  of  a 
backward  chain  of  subgoals,  subgoals  that 
have  already  been  proven  must  be 
"reproven"  based  upon  the  new  contents  of 
the  database.  Backward  chaining  would 
thus  be  very  complex  and  Inefficient. 

SDAR  uses  "procedural  attachments"  to  Its 
rules'  conditions  and  actions.  Procedures 
attached  to  rule  conditions  examine  the 
Data  Base,  but  also  compute  Information 
from  the  raw  data  stored  In  the  database 
and  Issue  navigation  sensor  commands. 
Procedures  attached  to  rule  actions 
manipulate  the  database  In  addition  to 
sending  control  signals  directly  to  the 
Airframe,  Transmitter,  and  the  Camera 
System. 

Procedural  attachments  were  used  for  this 
research  because  they  yield  the  advantages 
of  both  the  rule-based  and  procedural 
software  architectures.  The  AI  rule-based 
architecture  provides  the  flexibility 
needed  to  evolve  Intelligent  behavior,  but 
generally  does  not  execute  In  real-time. 
The  standard  procedural  architecture  can 
often  execute  In  real-time,  but  Is 
relatively  Inflexible  and  high  level  goals 
are  unclear.  Procedural  attachments  In 
SDAR  provide  both  the  flexibility  and 
clarity  of  AI  systems  and  the  speed  of 
real-time  systems. 

Each  time  the  Inference  engine  Is 
executed,  the  action  of  exactly  one  rule 
Is  fired,  thus  generating  the  appropriate 
control  signals  to  RASP's  effectors.  The 
procedures  that  are  attached  to  rule 
actions  collectively  form  an  asynchronous 
control  system. 

SDAR  Is  a  hybrid  Al/control  system  In 
which  both  the  Al  component  and  the 
control  component  have  been  designed  to 
work  with  each  other.  Control  components 
normally  have  the  "luxury"  of  executing 
synchronously;  SDAR  must,  and  does, 
execute  asynchronously.  AI  components 
normally  have  the  "luxury"  of  executing 
relatively  slowly;  SDAR  must,  and  does, 
execute  In  real  time. 

The  Programming  Language  and  Processor 
Many  systems  developed  for  real-time  AI 
flounder  because  of  the  large  size  and 
high  cost  of  the  fielded  hardware.  The 
software  techniques  used  by  the 
theoretical  AI  researchers  are,  by 
necessity,  very  "fuzzy"  structures.  The 
very  complex  data  structures  result  In 
very  large  memory  requirements.  Use  of 
the  data  structures  requires  searching  or 
chaining  through  long  sequences  of  linked 
lists.  Current  AI  specialized  processors 
(l.e.,  TI/DARPA  CLM  and  Symbolics  IVORY) 
are  optimized  for  these  operations  by 
tailored  microcode,  memory  speed  aids  such 
as  caches  and  pipelines,  large  bulk  memory 
such  as  hard  disks,  and  20  to  30  MHz 
processor  clocks.  This  hardware  approach 
la  power  hungry,  expensive  and  heavy  for 
autonomous  vehicles.  The  very  features  of 
L'lsp  that  help  with  the  design  of  AI 
solutions  also  cause  the  problems  with 
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utilizing  Lisp  for  real-time  airborne 
systems . 

SDAR  Is  written  In  the  Forth  programming 
language  •  Forth  Is  similar  to  LISP  In 
that  It  uses  lists  as  Its  primary 
algorithmic  structure;  It  differs  from 
LISP  In  that  It  uses  stacks  Instead  of 
lists  as  Its  primary  data  structure.  The 
stacks  are  best  handled  by  a  postfix 
notation  Instead  of  LISP'S  prefix.  With 
Forth,  much  of  LISPs  generality  Is 
possible . 

Moreover,  Forth  has  an  enormous  advantage 
with  respect  to  hardware.  A  new 
processor,  the  RTX,  has  been  developed 
that  executes  the  Forth  language 
primitives  In  hardware  gate  logic.  Both 
LISP  and  Forth  normally  run  under  a 
virtual  machine  emulated  on  the  actual 
host.  The  RTX  Is  a  realization  of  the 
virtual  machine  In  use  for  Forth  since 
1969.  This  development  allows  high  level 
Forth  code  to  be  executed  at  unprecedented 
speeds.  The  RTX  la  small  and  Inexpensive 
thus  fitting  rasp's  packaging 
requirements.  SOAR  was  developed  by  this 
project  for  application  on  the  RTX 
processor . 

SOAR  consists  of  eight  components: 
database,  rule  base,  inference  engine, 
preplanner,  rule  compiler,  attached 
condition  procedures,  attached  action 
procedures,  and  database  malntalner. 


Inference  Engine 

The  Inference  engine  Is  the  heart  of  SOAR. 
It  Implements  the  match,  conflict 
resolution,  fire,  and  repeat  phases  of  the 
forward  chaining  algorithm.  The  Inference 
engine  implements  the  match  and  conflict 
resolution  phases  by  Iterating  through  the 
rules  In  the  SOAR  rule  base  to  find  the 
"best"  rule.  The  "best"  rule  Is  defined 
as  Che  rule  with  highest  priority  among 
all  rules  whose  condition  is  true. 


For  each  rule  that  Is  examined,  Che 
Inference  engine  first  determines  If  Its 
priority  Is  greater  chan  the  priority  of 
the  best  rule  found  so  far.  If  it  is  not, 
then  the  rule's  condition  Is  not 
evaluated.  If  it  Is,  Chen  the  rule's 
condition  clauses  are  evaluated  one  at  a 
time . 


For  each  condition  clause  chat  Is 
evaluated,  a  call  Is  made  to  a  short 
machine  code  routine  that  tests  Che 
result.  A  false  clause  causes  Immediate 
clearing  of  the  stack  elements  pushed  by 
the  other  condition  clauses  of  Che  rule. 
(This  Is  to  allow  condition  clauses  to 
pass  parameters  to  the  action  clauses 
without  concern  for  the  order  of  the 
logic.)  The  false  clause  also  clears  Che 
return  stack  to  abort  out  of  the  rule 
execution  and  return  to  the  Inference 
engine  for  consideration  of  the  next  rule. 
A  true  clause  simply  allows  the  condition 
part  of  the  rule  to  continue  executing. 

If  Che  last  condition  clauaa  evaluates 
true,  then  the  current  rule  Is  labeled  the 
beat  rule,  and  Che  executable  address  of 
the  rule's  action  la  saved.  The  process 
continues  until  all  the  rules  have  baen 
examined . 
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After  the  match  and  conflict  resolution 
phases  are  finished,  the  Inference  engine 
flreb  the  best  rule.  It  does  so  via  a 
subroutine  call  to  the  executable  address 
of  the  best  rule's  action  part.  When  Che 
action  has  been  performed  the  Inference 
engine  returns  control  to  the  high  level 
word  which  Initiates  another  execution  of 
Che  Inference  engine. 

In  traditional  rule-based  systems,  the 
match  and  conflict  resolution  phases  Are 
distinct.  In  the  match  phase,  the 
Inference  engine  evaluates  all  of  the 
rules'  conditions  (thus  forming  the 
conflict  set)  with  no  use  of  Che  rules' 
priorities.  Then,  If  the  conflict  set 
contains  more  than  one  rule,  the  conflict 
resolution  phase  examines  the  priorities 
of  those  rules  to  determine  which  to  fire. 
(The  rule  ordinal  position  Is  not  useful 
for  resolving  the  conflict  because  Che 
rules  are  order  Independent.)  Thus  In 
traditional  rule-based  system,  the  match 
phase  Is  inefficient  because  every  rule 
condition  Is  evaluated  every  time  the 
Inference  engine  Is  executed.  This  is 
very  time  consuming  for  a  system  with  many 
rules  (>2000). 

The  "Rete  Algorithm"  Is  a  highly  respected 
approach  for  efficiently  Implementing  the 
match  phase.  Rete  uses  the  fact  that  most 
rule  conditions  use  a  very  small  portion 
of  the  data  base.  If  the  pertinent  data 
has  not  changed  since  the  last  execution 
of  the  Inference  engine,  the  rule 
condition  must  have  the  same  logical 
value.  The  idea  is  to  only  evaluate  the 
rule  conditions  chat  have  a  chance  of 
changing  their  state.  Therefore,  all 
changes  to  the  data  base  are  monitored, 
which  Is  simple  If  only  rule  actions  can 
change  the  database.  The  Rete  algorithm 
must  have  compiled  tables  defining  which 
clauses  or  rule  conditions  can  be  affected 
by  given  database  changes. 

The  Rete  algorithm  only  helps  when  the 
database  changes  slowly.  In  SOAR  this 
condition  Is  not  met.  The  conflict 
resolution  phase  Is  unchanged  by  Rete. 

The  rule  priorities  are  not  considered 
until  after  the  conflict  set  Is  formed. 

As  described  above,  SDAR's  Inference 
engine  interleaves  the  match  and  conflict 
resolution  phases  for  efficiency.  The 
Idea  of  examining  a  rule's  priority  before 
Its  condition  was  invented  (Independently 
at  NAVAIROEVCEN ,  although  perhaps  not 
exclusively)  In  the  course  of  developing 
Che  SOAR  Inference  engine.  This  method 
evaluates  a  rules  condition  clause  only  If 
the  associated  priority  is  high  enough. 

It  is  believed  that  this  algorithm  has 
more  speed-up  potential  than  Rete  for 
sensor  driven  database  applications. 


Fr eplanner 

The  Preplanner  Is  executed  before  RASP  is 
launched  and  Is  the  Interface  between  Che 
mission  planner  and  RASP.  Through  the 
preplanner,  the  mission  planner 
communicates  the  ship  Importance 
specification  and  the  mission  plan  to 
SOAR. 


More  precisely,  the  preplanner  assigns 
values  to  the  arrays  which  relate  a  ship's 
length,  speed,  heading,  distance,  and 
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direction  to  Its  length-value,  speed- 
value,  heading-value  distance-value  and 
direction-value  (respectively)*  It  also 
asalgns  values  to  the  variables  used  to 
coablne  those  Individual  values  Into  a 
total  value:  length-factor,  speed-factor, 
heading-factor,  distance-factor, 
direct  Ion- factor,  Iphoto-sesslons-factor, 
Interest-factor  and  handiness-factor* 

The  preplanner  assigns  values  to  the 
arrays  used  to  conpute  length-value, 
speed-value,  and  heading-value  to  length- 
factor,  speed-factor,  and  heading-factor, 
via  an  Interactive  session  with  the 
alsslon  planner*  The  preplanner  slaply 
assigns  constants  to  all  other  arrays  and 
variables  * 

The  preplanner  assigns  a  value  to  the 
mission  plan  through  a  similar  Interactive 
session  * 

Rule  Compiler 

The  SOAR  rule  compiler  takes 
condition/action  rules  and  produces 
executable  object  code*  The  rules  are 
compiled  Into  two  data  structures  In 
memory*  The  actual  object  code  that 
fetches  or  calculates  the  truth  status  of 
a  clause  Is  compiled  the  same  as  all  the 
other  software  In  the  processor*  In 
addition  the  executable  addresses  of  the 
condition  and  action  rule  parts  are  scored 
In  a  data  array  called  the  rule  list*  The 
rule  priorities  are  also  stored  In  the 
rule  list*  The  object  code  for  the  rule 
clauses  la  compiled  as  call  address  tables 
for  the  procedural  attachments*  The  last 
call  In  each  clause  Is  Co  a  machine  code 
routine  to  test  the  clause  truth  and 
directly  manipulate  the  return  stack 
accordingly* 

The  compiler  takes  full  advantage  of  the 
programmer's  access  to  compiler  primitives 
In  Forth*  The  SOAR  rule  base  compiler 
takes  pages  of  ASCII  text  source  code  and 
produces  executable  machine  code  optimized 
for  execution  by  the  Inference  engine* 

The  programmer's  access  to  Che  fundamental 
operating  system  variables  and  the  control 
the  programmer  has  over  Che  structure  of 
the  dictionary  facilitate  the  detailed 
manipulation  of  Che  machine  code  laid  down 
by  the  compiler* 

The  last  crucial  capability  used  In  Che 
SOAR  rule  compiler  Is  Che  control  of  the 
execution  time  of  s  defined  word*  In  the 
SOAR  rule  compiler  a  three  distinct  "run¬ 
times"  are  used,  corresponding  roughly  to 
"passes"  In  a  standard  compiler*  The  time 
phases  are  1)  during  the  compilation  of 
the  compiler  2)  during  execution  of  the 
compiler,  that  is,  compile  time  for  the 
rules  3)  during  the  execution  of  the 
compiled  rules*  A  lower  lavel  word 
defined  for  use  In  a  compiling  word  may  be 
easily  constructed  to  affect  the 
dictionary  and  the  stack  at  any  of  the 
three  time  phases*  It  Is  these  words 
executing  at  the  two  compile  tlmee  end 
menlpulatlng  the  dictionary  that  makes  the 
SOAR  rule  compiler  simple* 

Simulation  of  RASP 

A  computer  simulation.  Incorporating 
mathematical  models  of  the  non-SDAR 
components  of  RASP  and  Its  environment, 
was  produced  to  provide  e  test  bed  for 


SOAR  development*  The  major  components  of 
the  simulation  and  their  relation  to  the 
SOAR  Is  shown  In  Figure  2* 

The  simulation  was  developed  separately 
from  SOAR*  In  order  to  provide  the  most 
realistic  test  for  SOAR  the  simulation 
variables  such  as  aircraft  position  are 
not  directly  available  to  the  SOAR  system* 
Simulated  navigation  sensors  have  access 
to  the  perfect  knowledge  in  the  simulation 
models  and  make  that  Information  available 
to  SOAR  after  including  error  modeling* 
Initially  the  real-time  control  of  the 
Airframe  and  Camera  System  was  done 
manually*  Next,  the  autopilot  was 
Implemented  and  tested  under  various 
waypoint  configurations  and  wind 
conditions*  Finally,  SOAR  was  included 
and  rules  were  loaded  Incrementally  to 
debug  the  RASP  behavior  one  state  at  a 
time* 

The  simulation  was  run  repeatedly  with 
different  scenarios  to  Judge  the 
appropriateness  of  SDAR's  decisions*  As  a 
result,  SDAR's  rules  were  edited  several 
times*  The  flexibility  of  the  rule-based 
approach  made  It  a  simple  matter  to  do 
such  editing*  The  maneuver  efficiencies 
and  stabilities  were  also  tuned  during  the 
system  integration  phase* 

Before  the  simulation  begins,  the  user 
executes  the  preplanner  to  enter  a  mission 
plan  and  a  ship  Importance  specification* 
The  preplanner  displays  a  map-view  of  an 
area  of  ocean  on  a  video  screen*  The  user 
Chen  specifies  a  mission  plan  by 
repeatedly  using  cursor  keys  to  choose 
points  on  the  map*  Each  chosen  point  thus 
becomes  a  waypoint  of  the  mission  plan* 

As  the  cursor  moves,  the  screen  displays 
Its  position  In  miles*  The  generated  list 
of  waypoint  positions  can  be  stored  on 
disk  with  a  keystroke*  These  can  also  be 
easily  edited* 

The  user  enters  a  ship  Importance 
specification  through  a  four-phased 
dialogue  using  a  keyboard  and  video 
screen*  In  Phase  1  the  user  specifies 
which  ships  (in  terms  of  their  lengths: 
are  large  ships  Important  or  small  ones?) 
should  be  considered  Important  and  he  does 
so  by  Interactively  filling  In  a  table 
that  relates  esch  feasible  ship  length  to 
a  number  In  the  range  0  to  100  (the 
"length  value"  of  a  ship  with  that 
length)*  Phase  2  does  the  same  Job,  but 
for  ship  speed*  (Are  fast  ships  Important 
today?  Slow  ones?)  Phase  3  does  the  same 
Job,  but  for  ship  heading*  (Are  ships 
heading  north  Important  today?  East?)  In 
Phase  A,  the  user  specifies  the  relative 
weights  thst  should  be  used  by  RASP  to 
compute  a  shlp'a  Importance  from  Its 
length  value,  speed  value,  and  heading 
value,  as  defined  In  Phases  1-3*  The  user 
also  specifies  RASP's  environment*  The 
positions,  headings,  and  speeds  of  ships 
are  specified  through  a  process  that  is 
similar  to  the  mission  plan  specification* 
The  user  can  specify  the  direction  and 
speed  of  the  wind* 

During  Che  simulation,  the  behavior  of 
RASP  and  the  ships  Is  displayed  on  three 
video  screens:  Che  nap  view  screen,  the 
slrborne  camera  screen,  and  tha  system 
status  screen*  Tha  map  view  screen 


graphically  displays  a  map  of  aa  area  of 
ocean.  It  shows  (1)  the  waypoints  of  the 
mission  plan,  (2)  the  track  of  RASP's 
platform  through  time,  (3)  the  "footprint" 
of  rasp's  camera  on  the  ocean's  surface 
through  time,  (4)  the  actual  track  of  each 
ship  through  time,  and  (5)  the  estimated 
track  of  each  ship  that  has  been  sighted 
but  is  Currently  not  In  the  field  of  view 
through  time.  The  map  view  screen  also 
Indicates  when  RASP  Is  transmitting  to  the 
home  ship  by  "beeping". 

The  Airborne  Camera  screen  graphically 
displays  what  is  seen  by  RASP  at  each 
Instant.  More  precisely,  when  a  ship  Is 
In  rasp's  field  of  view,  a  synthesized 
Image  of  the  ship  appears  on  the  airborne 
camera  screen.  The  orientation  of  the 
Icon  is  correct,  and  Its  length  Is 
accurately  scaled.  The  system  status 
screen  Is  an  alphanumeric  display  that 
shows  data  concerning  the  current  state  of 

rasp. 


conclusions 

This  project  has  resulted  In  a  system  that 
breaks  the  bottleneck  that  has  previously 
prevented  use  of  artificial  Intelligence 
for  real-time  control  appl lea t Ions ^In 
unmanned  air  vehicles  (UAVs).  A  P'^I 
solution  has  been  developed  at 
NAVAIROEVCEN  to  make  dumb  sensor  platforms 
(l.e.  Remotely  Piloted  Vehicles  (RPVs)) 
Into  smart  UAVs  In  the  early  SOs.  This 
work  has  led  to  our  role  In  a  Trl-Servlce 
Joint  Program  Office  effort  to  flight  test 
autonomous  aircraft  maneuvering  to 
optimally  position  sensors.  This  work  has 
also  led  to  novel  systems  of  sensors  and 
platforms  potentiating  systems  such  as  the 
Tactical  Imaging  System  that  can  transmit 
Imagery  over  satcom  links.  In  addition  a 
variant  ^f  SOAR  Is  being  developed  to 
assist  C  operators  on  manned  aircraft. 


SENSORS  EFTECTORS 


Figure  1 .  Sensor  Driven  Airborne  Replanner  System  Architecture 


CAMERA  SIMULATION 


Figure  2.  SOAR  Laboratory  Simulation 


Discussion 


I.  F.VacMfdi,  Italy 

(a)  What  is  the  flight  altitude? 

(b)  Is  the  system  usable  in  all  weather? 

(c)  Is  the  system  equipped  for  ECM? 


Author; 

(a)  The  altitude  used  is  6000  ft. 

(b)  Only  good  weather  is  included  for  the  environment. 

(c)  No,  the  system  is  currently  used  only  for  civil  appli 
cations. 
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^  L.  SUMMARY 

TMS  -  the  Threat  Management  System  -  is  a  com¬ 
pany  prototype  development  of  a  support  system 
fcv  the  crew  of  nghter  bombers  at  low  level 
flight  In  p^cular  TMS  is  supposed  to  provide 
suf^rt  in  high  dense  groundba^  airdefence  sce¬ 
narios  during  the 

I  ^  preparation  phase ; 

>  penetration  phase  tu  r  ^ 

)  attack  phase^ 

^  of  a  mission  applying  methods  of  terrain  and 
threat  avoidance  combined  with  sensor  information 
fusionA 


2..  INTRODUCTION 

In  reaction  to  growing  capabilities  of  modem  airde¬ 
fence  systems  both  groundbased  and  airborne  and 
thus  to  increasing  r^uirements  for  mission  en¬ 
forcement  modem  military  aircraft  are  character¬ 
ized  by  increasing  system  complexity.  The  compo¬ 
sition  of  a  growing  number  of  demanding  sub¬ 
systems  imposes  additional  workload  and  thus  in 
consequence  operational  problems  to  the  crew  of 
such  integrated  systems.  In  order  keep  these  com¬ 
plex  systems  manageable  by  the  crew  also  in  fu¬ 
ture  oj^rating  in  complex  scenarios  several  nation¬ 
al  programs  like  Pilot's  Associate,  Mission  Man¬ 
agement  Aid  ,or  Copilote  Electronique  have  been 
launched  to  investigate  solutions  by  applying  new 
software  technologies  like  Artificial  Intelligence 
in  particular  knowledge  based  systems.  TMS  is  a 
project  within  this  scope. 


2iL  Scenario 

High  dense  groundbased  airdefence  scenarios  are 
best  described  by  multiple  layers  of  overlapping 
threat  areas  given  by  the  active  radii  of  the  missile 
systems.  Such  airdefence  belts  equipped  with  very 
effective  weapons  have  to  be  peneirat^  in  order  to 
get  to  preplanned  taigets. 

Today’s  general  procedure  for  penetrating  such  sce¬ 
narios  is  the  combination  of  high  velocity,  low  set 


clearance  height  and  the  application  of  any 
(onboard)  ECM  as  appropriate. 


2^  Cockpit  Situation 

increasing  system  and  scenario  complexity  means 
that  the  crew  has  to  cope  with  larger  amounts  of 
data  in  shorter  time  by  correlating  this  informa¬ 
tion  flow  mentally  under  stress  conditions.  In 
case  of  a  single  event  they  might  be  able  to  manage 
the  situation  but  for  several  simultaneously  ap¬ 
pearing  problems  it  is  almost  impossible  for  hu¬ 
man  beings  to  solve  the  problems  taking  into  ac¬ 
count  all  effecting  constraints.  Therefore  it  be¬ 
comes  more  and  more  important  to  provide 
suitable  onboard  support  systems. 


2,1  Development  Goals 

Onboard  support  systems  for  the  crew  of  future 
airborne  weaiwn  systems  need  to  provide 

•  comprehensive  situation  awareness 

*  tactical  recommendations  for  decision  making 

in  order  to  avoid  human  beings  becoming  the  limit¬ 
ing  factor  for  system  performance,  but  put  man  in¬ 
to  action  where  he  is  unique  as  system  manager  and 
final  decision  point. 

Modem  information  technology,  particularly 
methods  of  Artificial  Intelligence,  allow  super¬ 
vised  autonomous  functionality  on  lower  levels  of 
intellectual  capability  like  perception,  deduction, 
rulebased  knowledge  processing,  and  execution  of 
well  dcHned  tasks.  Therefore  functions  like 
search,  control,  transformation,  interpretation, 
evaluation,  and  also  planning  can  been  taken  over 
by  systems  based  on  such  m^em  software  technol¬ 
ogies  in  combination  with  conventional  algorith¬ 
mic  solutions. 

By  suppm  of  such  systems  the  workload  in  the 
coclq>it  implied  by  many  low  level  operational 
tasks  will  be  reduc^  and  the  crew  can  concentrate 
on  hmh  level  decisions  based  on  compact,  correlat¬ 
ed  information,  what  leads  to  an  improvement  of 


•  survivability  and 

•  mission  success. 

The  main  goal  of  the  system  is  the  onboard  sup¬ 
port  for  the  crew  in  critical  situations.  Only  if  ad¬ 
vised  by  the  crew  or  in  well  defined  situations 
TMS  should  take  over  the  aircraft  control. 


2.4  Application  Areas  for  Onboard  Knowledge 
Based  Systems 

Based  on  the  above  described  situation  several  dis¬ 
tinct  application  areas  of  complementing  knowl¬ 
edge  based  systems  in  combination  with  algorith¬ 
mic  procedures  can  be  derived. 

Providing  the  best  available  scenario  information 
is  one  essential  task  The  information  from  several 
sources  at  different  levels  of  detail  gained  at  dif¬ 
ferent  times  and  affect  by  some  degree  of  uncertain¬ 
ty  has  to  be  combined  to  a  consistent  description 
of  the  threatening  scenario  the  aircraft  has  to  oper¬ 
ate  in. 

Next  this  detected  scenario  has  to  be  assessed  in 
terms  of  threat  levels  for  the  aircraft  having  in 
mind  the  capability  of  the  aircraft  and  its  ontoard 
resources  and  weighting  this  against  the  features  of 
the  groundbased  airdefence  systems.  A  complete 
situation  assessment  requires  also  detailed  know¬ 
ledge  about  the  status  of  the  own  platform  com¬ 
bined  with  information  about  limitations  in 
flight  envelope  or  sensor  support  in  due  to  sub¬ 
system  failures.  The  emergency  procedure  manage¬ 
ment  has  to  be  taken  over  by  the  system. 


Based  on  this  evaluation  an  onboard  situation  de¬ 
pendent  plan  for  an  flight  route  through  the  sce¬ 
nario  can  be  generated  in  order  to  minimize  the  ex- 
ponadon  to  threats.  Terrain  masking  based  on  digi¬ 
tal  terrain  data  and  the  threat  scenario  in 
combination  with  silent  navigation  like  TRN 
CTerrain  reference  navigation)  is  a  propw  mean  for 
covert  operaticm  and  thus  for  threat  avoidance.  The 
planning  system,  has  to  keep  in  mind  the  very 
strict  limitations  of  time  and  fuel  management  for 
a  mission. 

In  order  to  sup{X'ess  the  effectiveness  of  the  airde¬ 
fence  systems  of  the  given  scenario  a  planning  sys¬ 
tem  for  tactical  measurements  provides  advice  for 
the  applicadon  of  onboard  ECM  equipment,  flight 
maneuver,  and  weapons  in  combinadon  with  a  re¬ 
sources  management 

Of  parUcular  importance  for  manned  aircraft  is  the 
man-machine-interface.  In  situadon  dependent  for¬ 
mats  providing  just  the  required  informadon  the 
decision  base  for  the  crew  has  to  be  displayed.  Us¬ 
er  modeling  allows  for  an  adaption  to  the  level  of 
experience  of  the  crew  if  appropriate. 


2^  THE  THREAT  MANAGEMENT  SYSTEM 

TMS  covers  a  particular  area  out  of  the  set  of  pos¬ 
sible  applicadons  of  software  technology  for  mili¬ 
tary  aircraft  based  on  the  above  outline.  Scenarios 
in  which  TMS  provides  its  support  are  best  de¬ 
scribed  by  high  dense  layered  groundbased  airde¬ 
fence  belts  like  the  so  called  European  scenario 
(figure  1). 


Figure  1:  Example  of  an  European  scenario 
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The  realized  basic  functionality  of  TMS  is 

•  recognition  of  the  actual  scenario 

•  threat  assessment 

•  planning/replanning  of  an  optimized  flight- 
path 

•  tactical  display. 


3.1  TMS  Concept 

Three  main-components  form  the  Threat  Manage¬ 
ment  System  (figure  2) 

•  Data/Information  Fusion 

•  Situation  Assessment  and  Plan  Generation 

•  Man/Machine  Interface 

These  components  are  embedded  in  a  simulation  en¬ 
vironment  for  development,  test  and  demonstra¬ 
tion  of  TMS  outside  a  real  target  system. 


Simulation  Environment 
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Figure  2:  System  Concept 


3.2  Simulation  Environment 

For  TMS  a  quite  elaborated  dynamic  simulation  en¬ 
vironment  hiu  been  develop^  in  order  to  feed 
TMS  with  realistic  data  as  far  as  its  functionality 
is  concerned.  Such  an  environment  allows  for  sys¬ 
tem  verification  up  to  a  high  degree. 

The  simulation  environment  is  composed  of 

•  digital  terrain  and  cultural  data 

•  groundbased  airdefence  sites 

•  dynamic  emitter  models 

•  aircraft  model 

•  ECM  sensor  models 

and  provides  features  for  setting  up  any  ground- 
based  scenario  out  of  the  list  m  available  airde- 
fence  sites.  Each  emitter  might  be  assigned  its  spe¬ 
cific  parameters  including  its  scanpattem  within  a 
selected  sector.  The  aircraft  model  can  be  equipped 
with  one  or  more  ECM  senscM'  model  providing  po¬ 
sition  and  attitude  at  each  instance  to  the  sensor 
models  for  evaluation  of  the  receiving  conditions. 

The  simulation  is  realized  by  means  of  object  ori¬ 
ented  programming  completely.  Classes  for  sites. 


emitters,  aircraft,  sensors  etc.  have  been  created. 
They  include  the  behavioral  description  of  an  ob¬ 
ject  and  inherit  it  to  son  objects..  Instances  de¬ 
scribe  a  particular  realization  of  an  object.  Actions 
are  initiated  by  messages. 

For  a  future  development  a  knowledge  based  mod¬ 
ule  will  control  a  tactical  behavior  of  the  threats, 
e.g.  control  of  moding  depending  on  the  approach 
of  the  aircraft  and  doctnnes.. 


3J  Information  Fusion 

The  growing  number  of  information  sources  on¬ 
board  milita^  aircraft  requires  means  for  merging 
the  information  about  the  same  object  from  differ¬ 
ent  sources  to  one  cominehensive  display  as  infor¬ 
mation  source  for  the  crew.  Beside  active  and  pas¬ 
sive  onboard  sensors  operating  in  different  frequen¬ 
cy  slots  and  directions  with  different  sensitivity 
and  resolution  radio  links  to  remote  sources  are  in 
use.  Also  intelligence  information  about  the  dif¬ 
ferent  orders  of  battle  (MOB,  EOB,  AOB,  GOB) 
as  briefing  data  as  well  as  digital  terrain  and  cul¬ 
tural  data  are  important  information  sources  for 
deriving  best  knowledge  about  the  actual  threat 
scenario. 
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33.1  Fusion  Concept 

The  TMS  fusion  component  is  based  on  infOTma- 
tion  from  passive  sensors  alternatively  cme  or  both 

•  RWR  -  Radar  Warning  Receiver 

•  ESM  -  Location  Receiver 

and  on  the  two  data  sources 

•  prebriefed  scenario 

•  digital  terrain  data. 

Other  sources  can  be  integrated  but  are  not  in  use 
right  now. 

At  the  first  instance  of  operation  of  the  fusion 
unit  its  output  is  identical  with  the  contents  of 
the  prebrief^  scenario.  If  time  proceeds  it  will  be 
updated  continuously  by  actual  information  about 
the  real  scenario. 

A  Basic  Combiner  provides  fundamental  function¬ 
ality  like  the  administration  of  the  incoming  infor¬ 
mation  from  different  sources,  the  keeping  of  the 
combined  tracklist,  the  resolution  of  idendHca- 
tion  conflicts,  and  the  management  of  higher  lev¬ 
els  of  the  fusion  process.  TMS  knows  three  levels 
of  specific  fusion  operations 

•  the  geometric  combiner 

•  the  geographic  combiner 

•  the  tactical  combiner. 

with  each  of  them  requiring  an  increasing  amount 
of  processing  time.  The  geometric  combiner  pro¬ 
cesses  primarily  identification-,  direction-  and  dis¬ 
tance  information  provided  by  the  different  sourc¬ 
es.  The  location  of  an  emitter  measured  by  a  sen¬ 
sor  is  attached  with  an  uncertainty  about  its  real 
position.  The  geographic  combiner  reduces  the  loca¬ 
tion  error  by  analyzing  terrain-,  surface-,  and  cul¬ 
tural  data  of  the  surrounding  area.  Finally  the  tac¬ 
tical  combino-  processes  knowledge  about  the 
Ground  Order  of  Battle  and  the  equipment  of  the 
related  units  as  well  as  doctrines  for  deployment 
and  tactical  behavior. 

The  information  fusion  can  be  enhanced  by  an  addi¬ 
tional  sensor  management  unit,  which  coordinates 
situation  dependent  the  usage  of  the  different  on¬ 
board  sources  by  techniques  of  mode  selection  and 
sensor  cueing. 


332,  Fusion  System  Architecture 

The  selected  architecture  for  the  TMS  information 
fusion  unit  is  based  on  blackboard  system  concepts 

The  blackboard,  a  global  database,  keeps  the  actual 
problemsolving-state.  It  consists  of  inputdata, 
potial  solutions,  alternatives  and  final  solutions, 
all  of  them  objects  of  the  solution-space.  They  are 
hierarchical  organiiml  into  levels  of  analysis; 
therefore  sensovdata  arrive  at  the  lowest  level. 
The  datastructure  on  the  blackboard  is  a  dynamic 
entity  that  evolves  over  time  representing  the  cur¬ 


rent  best  hypothesis.  The  knowledge-sources 
(geometric,  geographic,  tactical)  respond  opportu¬ 
nistically  to  changes  on  the  blackboard  driven  by 
the  focus  of  attention. 


3.4  Advisor 

3.4.1  Situation  Assessment 

Based  on  the  output  information  of  the  fusion 
unit,  the  combined  scenario,  TMS  assesses  the  de¬ 
gree  of  danger  of  separable  areas  of  the  scenario  de¬ 
pendent  on  threat-type  and  areas  of  overlapping 
nghting  zones.  The  result  of  this  assessment  is  a 
threat-map  displaying  weighted  threat-areas  on  a 
digital  map.  We  have  selected  circles  representing 
the  fighting  zones  of  threats  because  the  more  de¬ 
dicated  pattern  depend  on  the  direction  an  aircraft 
is  approaching  a  site  and  this  information  isn’t 
available  for  the  first  iteration. 

Once  an  aircraft  is  tracked  by  an  emitter  its  prima¬ 
ry  task  is  to  unlock  the  track  before  a  missile  can 
be  launched.  One  mean  for  this  is  to  use  areas 
masked  by  terrain  for  the  flight  route,  i.e.  areas 
which  can’t  be  controlled  by  a  radar  because  of  the 
structure  of  the  terrain.  To  provide  this  terrain 
and  threat  avoidance  functionaJity  TMS  calculates 
a  more  detailed  threat-map  where  both  threat  de¬ 
ployment  and  terrain  masking  is  considered 
(figure  3). 

Part  of  situation  assessment  is  the  actual  know¬ 
ledge  about  the  status  of  the  own  platform,  be¬ 
cause  any  limitation  due  to  subsystem  failure  de¬ 
creases  the  capacity  of  the  aircraft  and  thus  effects 
the  plan  generation  massively.  System  status  eval¬ 
uation  isn’t  in  the  scope  of  TMS  right  now. 


3.4.2  Tactical  Advice 


Based  on  the  previous  described  situation  assess¬ 
ment  suitable  measures  can  be  planned  to  reduce 
the  risk  for  crew  and  platform.  Generally  the  pro¬ 
cedures 

•  avoidance 

•  reduction  of  detectability 

•  deception  and  jamming 

•  fighting 

are  possible.  The  tactical  advisor  selects  and  com¬ 
bines  these  measures  situation  dependently. 

Tactical  experience  is  heuristic  knowledge  gained 
in  a  multitude  of  simulation,  training  flights,  and 
sorties  continuously  being  up^ted  and  adapted  to 
new  develcqiments.  Thus  despite  some  general  pro¬ 
cedures  the  knowledge  base  of  an  tactical  advisor 
must  be  tailored  to  the  respective  conOguration  of 
the  aircraft  and  to  the  knowledge  about  the  capa¬ 
bility  of  the  systems  in  the  scenario. 

TMS  is  supposed  to  provide  both  capacities  route 
planningAeplanning  and  plan  generation  for  use  of 
onboard  resources  in  combination  with  appropriate 
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tnaneuveis. 

3.4J.1  Rerouting 

Detected  differences  to  the  prebriefed  scenario  or 
sudden  changes  require  a  replanning  of  the  pre¬ 
planned  mission  route  based  on  the  mission  goals 
and  the  actual  knowledge  about  the  scenario.  TMS 
provides  a  route  planner  that  can  be  applied  for 
global  mission  route  planning  as  well  as  for  local 
rerouting.  It  takes  into  account  constraints  for 
time-  and  fuel-consumption  and  makes  sure  that 
the  replanned  route  is  in  the  neighborhood  of  the 
preplanned  mission  route.  Similar  important  is 
that  the  route  planner  inherently  avoids  routes 
which  lead  into  a  dead  end.  Critical  sections  of  the 
flight  path  can  be  seen  on  the  display  (figure  3). 

Route  planning  for  terrain  and  threat  avoidance  re¬ 
quires  not  only  lateral  but  also  vertical  route  com¬ 
ponents.  The  consequence  is  that  a  modified  3-D 


flight  control  algorithm  has  to  be  developed 
which  allow  to  follow  such  a  preplanned  route. 


3.4.2.2  ECM  Advisor 

Route  planning  and  replanning  reduces  the  expona- 
tion  of  the  aircraft  to  threats  and  minimizes  the 
time-interval  of  crossing  a  fighting  zone,  but  it 
doesn’t  eliminate  the  threat.  Therefore  it  is  impor¬ 
tant  to  plan  the  employment  of  onboard  resources 
in  combination  with  flight  maneuvers.  Onbord  re¬ 
sources  are  limited  therefore  it  is  important  to  em¬ 
ploy  them  purposeful  adapted  to  the  current  situa¬ 
tion  and  to  manage  their  consumption  having  the 
needs  for  the  overall  mission  in  mind.  Unplanned 
flight  maneuvers  within  a  highden.  ’  scenario  are 
very  critical  because  they  might  directly  lead  into 
an  exponation  to  several  threats. 


a 
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Figure  3:  Tactical  Display 
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2jS.  Man-Machine  Interface 

At  the  man-machine  interface  the  required  informa¬ 
tion  has  to  be  provided  to  the  crew  of  airborne 
platforms  situation  dependently  in  compact  but 
comprehensive  form.  A  combination  of  a  2-D  top- 
down  view  tactical  color  display  providing  the 
overview  about  the  scenario  on  t^  of  a  map  and 
the  planned  route  ova’  a  long  distance  (figure  3) 
and  a  perspective  3-D  display  showing  the  situa¬ 
tion  ftM-  the  next  seconds  of  flight  are  in  use  with 
TMS  respectively  under  devek^mienL 


iu  development  environment 

The  TMS  prototype  completely  is  develt^ted  in 


CLOS  (Common  Lisp  Object  System)  for  means  of 
flexibility,  maintainability  and  control  of  com¬ 
plex  data  structures.  Therefore  a  development  envi¬ 
ronment  as  shown  in  figure  4  is  applied.  Parts  of 
TMS  meanwhile  could  be  proved  providing  valid 
functionality  and  therefore  are  in  the  process  of  be¬ 
ing  ported  to  target  processors  like  680xx  or 
R3000. 


REAL-TIME  ASPECTS 

At  least  three  levels  of  real-time  have  to  be  con¬ 
sidered 

•  Reaction  times  less  than  one  second;  A  new 
upcoming  threat  has  to  be  displayed  immedi¬ 
ately  to  the  crew.  Fast  algorithms  for  in- 


formation  fusion  can  be  applied. 

•  Response  times  at  about  one  second:  The 
route  planner  for  example  plans  a  new 
route  over  100  miles  within  this  time¬ 
frame.  Because  route  replanning  is  initiated 
by  changes  in  the  scenario  or  by  request  of 
the  pilot  this  processing  time  seems  to  be 
reason£d)le. 


•  Several  seconds  of  reaction  time:  Functions 
like  trend  monitoring  allow  several  seconds 
of  update. 

Thus  in  each  case  the  appropriate  time  scale  has  to 
be  analyzed  and  its  design  has  to  be  adapted  to  the 
allowance  in  functionality. 
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Figure  4:  Development  Environment 


Discussion 


Future  developments  in  avionics  systems  will 
adopt  integrating  support  systems  hke  TMS  in  an 
evolutionary  way.  For  onboard  application  of 
knowledge  based  systems  a  wide  area  of  functional¬ 
ity  has  b^n  identified  and  at  least  as  prototype  so¬ 
lution  resized.  The  major  challenge  for  the  next 
future  will  be  the  development  of  operational  sys¬ 
tems  in  target  environments. 


1.  Dr  K.  Holla,  Germany 

The  air  defenders  will  react  to  the  intelligent  threat  reaction 
systems,  and  a  viable  strategy  becomes  using  "spoof  or  false 
threat  emitters  to  try  and  channel  the  aircraft  to  heavily 
defended  corridors.  Do  you  consider  a  cost  association  with 
reacting  to  emitters? 

Author: 

From  my  view  to  beat  this  problem  you  need  at  least  three 
information  sources  (knowledge  sources):  Intelligence 
information  (prebriefed  data  to  know  where  sites  have  been 
.seen,  also  if  they  are  currently  not  active;  Remote  sensor 
information  about  communication  activities  to  know  the 
communication  links  and  the  superior  control  section;  and 
knowledge  about  doctrine  and  tactical  behavior  to  be 
prepared  for  such  “spoofing”. 
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2.  INTRODUCTION 


1.  RESUME 

If  est  generalement  admis  que  la  moitie 
du  coCit  d'utilisatlon  des  avions  de  combat 
correspond  aux  depenses  concernant  la 
maintenance  :  rechanges,  nombre  d'heures 
de  maintenance  par  heure  de  vol,  etc...  Pour 
r^dulre  ou  maitriser  ces  coOts,  II  est  essentlel 
de  d6velopper  un  concept  de  maintenance 
permettari  une  automatisation  et  une  fiabillte 
maximales  des  operations  de  diagnostic.  Oe 
plus,  ces  diagnostics  doivent  etre  les  plus 
fins  possibles,  le  but  final  etant  de  tendre 
vers  une  maintenance  deux  niveaux  (mainte¬ 
nance  en  ligne  el  maintenance  industrielle). 
Pour  tenir  ces  objectifs,  I'utilisation  de  I'lntel- 
llgence  Artificielle  appllquee  e  la  detection  el 
e  la  localisation  de  pannes,  fait  I'objet  de 
nombreuses  eludes  el  semble  etre  une  voie 
interessante  pour  la  resolution  du  probleme 
pose.  Le  systeme  de  diagnostic  developpe 
sur  les  avions  d'armes  de  DASSAULT  AVIA¬ 
TION  repose  sur  le  concept  de  la  maintenan¬ 
ce  integree  et  I'utilisation  de  rinlelllgence 
artificielle  est  blen  adaptee  8  ce  concept.  La 
principale  caracterlstique  de  cette  maintenan¬ 
ce  integree  est  de  realiser  la  detection  et  la 
localisation  de  pannes  par  verification  de  I'in- 
tegrite  des  elements  materiels  et  logiciels 
constituant  les  difterentes  chaines  fonctlon- 
nelles.  Ce  princIpe  est  utillsable  pour  la 
maintenance  sur  avion  (en  ligne)  et  en  atelier 
(hors  ligne  et  maintenance  Industrielle).  Les 
performances  interessantes  relevees  sur  les 
avions  actuellement  en  service  peuvent  etre 
ameilorees  de  fapon  sensible  par  I'utilisation 
de  I'Intelllgence  Artificielle  8  dlfterents 
niveaux. 


Un  systeme  performant  de  detection  et 
localisation  des  pannes  dolt  avoir  pour  objec¬ 
tifs  ; 

•  I'Accrolssement  de  la  securite  des  vols 

•  I'utilisation  optimale  des  systemes  de 
I'aeronef  en  cas  de  panne 

•  le  detection  et  la  localisation  des  pannes 
dans  un  temps  le  plus  reduit  possible 
(proche  du  temps  reel) 

•  une  fiabillte  du  diagnostic  la  plus  eievee 
possible  (taux  de  fausse  depose  le  plus 
reduit  possible) 

•  une  finesse  de  diagnostic  importante  (dia¬ 
gnostic  au  niveau  de  I'unite  remplapable 
en  atelihr  8  I'interieur  de  I'unite  rempla- 
cable  en  ^gne) 

Ces  objectifs  doivent  etre  atteints  si  I  on 

veut 

•  diminuer  les  te^ps  de  remise  en  etat 

•  diminuer  le  cout  'pn  rechanges 

•  diminuer  le  nombre  et  la  qualification  des 
mecaniciens. 

Pour  obtenir  le  resutfat  recherche.  II  est 
primordial  qu'au  debut  ^u  developpement 
d  un  systeme  d'armes,  II  Mit  etabll  la  politi¬ 
que  de  maintenabilite  maintenance  la  mieux 
adaptee  pour  I'ensemble  d^  constituants, 
tous  niveaux  de  maintenance  cenfondus. 
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Le  princIpe  de  maintenance  Int^gr^e  de 
DASSAULT  AVIATION  a  commence  ^  etre 
6tudi6  en  1978  et  a  depuls  ^18  appliqu^  d 
tous  les  syst6mes  d'Armes  d^velopp^s 
depuis  cette  date.  Ce  principe  est 
entidrement  algorithmique  et  a  des  perfor¬ 
mances  trds  intiressantes.  En  parallels,  nous 
avons  rdalis6  un  certain  nombre  d'6tudes  sur 
des  syst6mes  experts  destines  au  diagnostic 
de  pannes.  L'exp^rience  acquise  grdce  k  ces 
dtudes  n'a  pas  remis  en  cause  le  concept  de 
maintenance  int^grde,  mals  a  au  contraire 
montr^  qu'une  utilisation  conjolnte  de  ce  type 
de  maintenance  et  de  I'l.A.  permettait  d'envl- 
sager  un  accrolssement  important  des  perfor¬ 
mances.  Nous  allons  done  d8crire  le  principe 
de  la  maintenance  int6gree  et  indiquer  it 
quels  points  de  son  organisation  II  est  Inte- 
ressant  d'utiliser  des  systemes  experts. 


3.  PRINCIPE  DE  DIAGNOSTIC  PAR 
TEST  D'INTEGRITE 

Le  principe  essentiel  sur  lequel  repose  la 
maintenance  int6gr6e  est  le  test  d'lntegrite 
qui  peut  8tre  d6flnl  comme  suit  : 

•  quand,  pour  un  ^quipement,  on  teste 
separ^ment  I'int^grit^  du  logiciel  et  I'lnte- 
grit^  du  materiel,  I'ensemble  de  ces  deux 
tests  est  equivalent  a  un  test  d'lntegrite 
global 

•  quand,  pour  un  ^quipement,  on  leste 
s^par^ment  son  fonctionnement  interne  et 
ses  interfaces  avec  I'ext^rleur,  la  somme 
de  ces  deux  tests  est  ^quivalente  a  un 
test  d  int^grite  global 

•  quand,  pour  un  dquipement,  un  test 
garantit  I'int^grit^  de  I'^quipement,  ce 
test  garantit  le  bon  fonctionnement  de 
I'^quipement  et  11  n'est  done  pas  neces- 
salre  de  simuler  le  fonctionnement  pour 
valider  la  fonction  de  transfert  de  I'^qui- 
pement. 

•  Dans  la  mesure  oil  le  fonctionnement 
interne  de  I'dquipement  peut  6tre  modifld 
i  des  fins  de  recherche  de  panne,  ce 
fonctionnement  peut  8tre  utilise  pour  tes¬ 
ter  valablement  les  Interfaces  de  I'^qul- 
pement  avec  I'ext^rleur.  Exemple  :  en 
faisant  ex4cuter  s6par8ment  dans  I'iqul- 
pement  une  fonction  destln^e  uniquement 
d  en  valider  les  entr^es/sortles  et  un  test 
d'lntegrite  de  la  fonction  de  transfert,  on 
a  valide  requipament  aussi  bien  qua  par 
un  test  complet  par  simulation  de  fonc¬ 
tionnement. 

CecI  suppose  qua  la  mise  au  point  de 
requipament  a  ete  menee  correctement,  ce 
quI  est  I'hypothese  de  base  du  ralsonnement. 

Ces  principes  ont  pour  consequence  : 


•  de  permettre  des  tests  permanents  dans 
les  equipements.  En  effet,  un  test  d'inte- 
grlte  sur  le  fonctionnement  interne  de 
requipement  peut  n'avoir  aucun  effet  sur 
les  interfaces  de  celui-ci  et  ne  perturbe 
done  pas  le  reste  du  systeme 

•  de  simplifier  la  mIse  en  oeuvre  :  un  test 
par  simulation  de  fonctionnement  suppo¬ 
se  que  si  un  6qulpement  appartlent  d  une 
chatne,  toute  la  chaine  participe  au  test, 
alors  qu'un  test  d'lnt6grlt6  interne  est 
localise  dans  un  6quipement. 

•  de  permettre  un  fonctionnement  specifi- 
que  des  equipements  ^  des  fins  de 
controle  de  I'intdgrit^  des  interfaces.  Si 
ce  fonctionnement  est  etendu  a  I'ensem¬ 
ble  du  systeme,  II  est  alors  possible  de 
tester  les  Interfaces  des  equipements 
sans  se  pr6occuper  des  chalnes  fonction- 
nelles. 

•  de  simplifier  de  fagon  extremement 
Importante  la  base  de  connaissance  d'un 
systeme  expert  dedl6  au  diagnostic  de 
pannes.  En  effet,  les  modules 
comportementaux  des  Equipements  se 
rEduisent  a  des  modeles  de  fonction¬ 
nement  Electronique  de  cheque  Equi- 
pement  sans  se  prEoccuper  des  fonctlons 
de  transfert  assurees  par  logiciel. 

II  est,  par  allleurs,  important  de  souli- 

gner  les  points  suivants  : 

•  Les  tests  de  sEcuritE  des  Equipements 
sont  de  toute  fat;on  obllgatolres  pour 
assurer  la  sEcuritE  du  vol.  De  la  mEme 
manlEre,  des  tesis  sont  nEcessairement 
effectuEs  pour  prEvenIr  le  pilote  des 
dEgradations  du  fonctionnement  opE- 
ratlonnel  des  Equipements.  Si  ces  tests 
sont  convenablement  conpus,  leurs  rEsul- 
tats  peuvent  Egalement  servir  au  diagnos¬ 
tic  de  pannes,  sous  rEserve  qu'ils 
satisfassent  aux  performances  deman- 
dEes. 

•  Les  tests  destInEs  E  un  Echelon  de  main¬ 
tenance  donnE  peuvent  souvent  Etre  utili- 
sEs  avec  profit  E  un  autre  Echelon. 

•  SI  un  Equipement  est  Indus  dans  une 
chaine  fonctlonnelle,  et  s'il  existe  un 
moyen  de  dialogue  entre  les  Equipements 
de  la  chaine  (Bus  numErique  multiplexE 
par  exemple),  cet  Equipement  devra 
contribuer  E  la  maintenance  globale  de  la 
chaine  (par  exemple,  le  test  des  sorties 
de  cet  Equipement  pourra  fournir  des 
Informations  pour  le  test  des  entrEes  de 
I'Equipement  sulvant  dans  la  chaine). 


3.1.  PERFORMANCES  OEMANDEES  AUX 
EQUIPEMENTS 

Dans  la  construction  de  la  maintenabilltE 


globale  d'un  Systdme,  il  est  demand^  qua 
chaque  equipement  soft  con^u  avec  las 
objactifs  suivants  : 

•  Utilisation  maximale  das  capacit6s  inter¬ 
nes  das  dquipements  dans  la  but  da  limi¬ 
ter  at  da  standardiser  las  outillages  da 
maintenance 

•  Orientation  das  tests  vers  la  localisation 
de  ('element  an  panne 

•  Contribution  des  ^quipements  ii  la  main¬ 
tenance  de  i'ensemble  du  syst^me 

Par  "6l6ment"  on  entendra  ; 

•  i'Unite  Rempia^abie  an  Ligne  (URL) 
pour  ia  maintenance  an  Ligne 

•  i'Unite  Rempla^able  an  Atelier  (URA) 
pour  la  maintenance  hors  ligne 

•  la  composant  ^lementaire  pour  la 
maintenance  industrielle. 


3.2.  LIMITATIONS 

II  est  Evident  qua  I'ensemble  des  dispo¬ 
sitions  de  testability  appllcables  A  un  yqul- 
pement  conduit  nycessairement  y  des 
augmentations  de  matyriel  et/ou  togiclel 
embarquys.  Ces  augmentations  dolvent  ytre 
contrdlees  et  ryflychies  car  elles  peuvent 
entrainer  : 

•  Une  diminution  de  (iability 

•  Une  diminution  de  sycurlty 

•  Une  augmentation  de  poids  ou  de  volume 
«  Une  augmentation  du  prix 

II  est  done  nycessaire  dans  tous  les  cas 
d'examiner  tous  ces  aspects  de  faoon  y  ryali- 
ser  un  compromis  acceptable  entre  toutes 
ces  exigences  qui  sont  parfois  contradictoi- 
res. 

En  particulier,  il  est  nycessaire  sans  trop 
pynaliser  les  temps  d'exycutlon  des  procydu- 
res  de  maintenance,  d'exploiter  au  maximum 
les  possibilitys  offertes  par  des  moyens  mis 
en  oeuvre  au  sol,  solt  en  interne  au  systyme 
avionique  embarquy,  soit  en  exteme. 

Par  exempts,  pour  les  yquipements  com- 
portant  un  opyrateur  programmy  et  une 
memoire  vIve,  il  peut  apparaitre  prytyrable 
de  charger  les  programmes  de  test  et  de  les 
fairs  exycuter  en  mymoire  vIve  tors  des  opy- 
rallons  de  maintenance  ptutdt  que  de  les  fai¬ 
rs  rysider  en  permanence  en  mymoire 
programme  ;  on  yvlte  alnsi  de  pynaliser  la 
faille  de  la  mymoire.  on  dimlnue  les  probiy- 
mes  de  sycurlty  liys  y  la  maintenance,  et  on 
ne  demande  y  ryquipement  que  d'Mre  capa¬ 
ble  de  charger  et  d'exdcuter  ces  programmes 
dans  sa  zone  de  mymoire  vivs. 


4.  PRINCIPE  GENERAL 

d'organisahon  du  oepannage 

Le  dypannage  des  yquipements  est 
organisy  suivant  trots  niveaux  d'lnterven- 
tion  ; 

•  Maintenance  en  Ligne  avec  localisation 
des  Unites  Rempla^bles  en  Ligne  (URL) 

•  Maintenance  Hors  Ligne  des  yquipements 
avioniques  avec  localisation  des  Unitys 
Remplacables  en  Atelier  (URA) 

•  Maintenance  Industrielle  des  yquipements 
avioniques  avec  localisation  des  compo- 
sants. 

Le  dycoupage  matyriel  de  nos  systymes 
etant  organisy  en  Boltes  nolres,  nous  n'avons 
pas  pour  objectlf  principal  de  locallser  direc- 
tement  sur  avion  les  Unites  Rempla^ables  en 
Atelier  en  panne.  Cependant,  la  localisation 
d'URA  en  panne  est  possible  dans  un  certain 
nombre  de  cas  comme  nous  le  verrons  plus 
loin. 

D'autre  part,  tous  les  rysultats  des  dia¬ 
gnostics  effectuys  au  niveau  de  I'avlon  sont 
mymorises  sur  un  mydla  Informatique  et 
transmis  directement  y  I'atelier  hors  ligne 
pour  faclllter  les  opyratlons  de  diagnostic 
d'URA  en  panne  losque  celles-ci  ne  sont  pas 
localisees  au  niveau  de  I'avion.  De  la  myme 
maniyre,  les  testeurs  de  maintenance  hors 
ligne  constituent  une  base  de  donnyes  pour 
informer  la  maintenance  Industrielle  des 
rysultats  de  test  qui  ont  conduit  au  diagnostic 
de  panne  des  URA  dyposyes. 


5.  MAINTENANCE  EN  LIGNE 

La  maintenance  en  ligne  est  I'ensemble 
des  opyratlons  de  maintenance  exycutyes 
par  les  unitys  opyrationnelles  sur  leurs  ayro- 
nefs  en  utilisation.  On  distingue  deux  phases 
dans  la  maintenance  en  ligne  des  systymes  : 

•  Une  maintenance  en  temps  ryel,  pendant 
le  fonctionnement  opyrationnel  du  syste- 
me  pour  laquelle  I'accent  sera  mis  sur  les 
autotests  des  yquipements  avec  I'lmpyra- 
tif  de  ne  pas  perturber  le  fonctionnement 
normal. 

•  Une  mainter.mce  compiymentaire  au  sol, 
pendant  laquelle  I'ensemble  des  systy¬ 
mes  adopters  un  fonctionnement  adapty, 
qui  permettra  le  test  des  liaisons  inter- 
yquipements,  la  ryallsatlon  des  tests  trop 
perturbants  pour  ytre  effectuys  en  fonc¬ 
tionnement  normal,  etc... 

L'utillsatlon  de  la  maintenance  Intygrye 
offre  les  avantages  suivants  : 

•  MIse  en  oeuvre  quasl-lnstantanye 
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•  Grande  IndApendance  vis-A-vis  des  Evolu¬ 
tions  des  logiclels  des  Equipements 

•  Exploitation  sur  avion  des  rEsultats  avec 
possIbIMtE  d'avoir  un  bonne  connaissance 
des  pannes  qui  se  sont  produltes  en  vol 
et  qui  ne  sont  pas  toujours  decelables  au 
sol. 

•  Recherches  de  pannes  ou  validations 
sans  simulations  des  conditions  de  vol, 
d'oCi  une  plus  grande  rapidItE  d'exEcutlon 
des  procEdures 

•  REduction  trEs  importante  du  nombre  de 
moyens  de  tests  extErieurs  E  I'avion 

•  Maintenance  quel  que  soit  le  mode  de 
fonctionnement  opEratlonnel 

•  Grande  souplesse  dans  les  procEdures  de 
dEpannage 

•  Cablage  avion  spEcifique  k  la  maintenan¬ 
ce  tres  faible 

•  Faible  emprise  des  disposiiifs  de  mainte¬ 
nance  intEgrEe  sur  le  materiel  et  sur  le 
logiciel  des  Equipements. 


5.1.  MAINTENANCE  TEMPS  REEL 

Elle  s'appuie  essentiellement  sur  les  sur¬ 
veillances  et  autotests  permanents  non  per- 
turbants.  rEalisEs  par  les  Equipements  sur 
eux-mEmes  et  sur  leurs  periphErIques  de  la 
fa^on  la  plus  complEte  possible. 

Ces  tests  ont  pour  but  de  vErlfier  le  bon 
fontionnement  de  I'equipement  tant  au  plan 
du  matEriel  qu'au  plan  du  logiciel.  Ils  permet- 
tent  soit  de  dEtecter  une  panne,  dont  I'origlne 
peut  Etre  sure  ou  ambIgOe,  soit  un  retour  au 
bon  fonctionnement.  Les  rEsultats  de  ces 
contrdles,  aprEs  les  traitements  prEliminaires 
rEalisEs  au  niveau  de  I'Equipement,  sont 
Emis,  via  un  bus  numErique,  E  destination 
d'un  organe  de  calcul  central  qui  effectue  les 
tests  complEmentaires  sur  les  parties  des 
Equipements  ne  pouvant  pas  Etre  couvertes 
par  les  autotests  internes  (dialogue  bus  par 
example).  Puls  pour  chaque  Equipement, 
aprEs  flitrage  et  synthEse  Eventuels,  cet  orga¬ 
ne  assure  la  mEmorisation  et  la  datatlon  des 
EvEnements  relatifs  aux  Equipements.  C'est 
cet  organe  qui  est  chargE  d'en  assurer  la  res¬ 
titution  au  mEcanIcien  ou  au  pilote  au  retour 
du  vol.  Oans  ce  mode,  quand  la  localisation 
de  panne  peut  Etre  rEallsEe,  elle  est  auto- 
ntatlque. 


5.1.1.  FONCTIONNEMENT  DES  COMPTE8 
RENDUS  DE  MAINTENANCE  <CRM) 

C'est  sous  ce  vocable  qu'est  dEsIgnEe  la 
maintenance  temps  rEel  at  I'exploltatlon  qui 


en  est  falte  dans  I'avion.  Les  CRM  ont  une 
double  procEdure  d'utilisatlon  : 

•  Les  Comptes  Rendus  EnregIstrEs  (CRE) 

•  Les  Comptes  Rendus  InstantanEs  (CRI) 

5.1 .1.1  LES  COMPTES  RENDUS  ENRE  - 
GISTRES 

Ils  correspondent  aux  enregistrements, 
rEalisEs  dans  I'organe  de  calcul  central,  des 
evEnements  dEtectes  sur  les  Equipements,  et 
effectuEs  pendant  le  fonctionnement  opE- 
rationnel.  II  y  a  enregistrement  pour  chacun 
des  cas  sulvants  : 

•  Passage  d'un  Etat  de  bon  fonctionnement 
a  un  Etat  de  panne 

•  Passage  d'un  Etat  de  panne  E  un  autre 
Etat  de  panne 

•  Passage  d'un  Etat  de  panne  E  un  Etat  de 
bon  fonctionnement. 

Ces  enregistrements  permettent,  au 
retour,  de  restituer  les  EvEnements.  Cette 
restitution  est  rEalisEe  sous  deux  formes  : 

•  Les  pannes  en  fin  d'utillsation 

•  L'historique  des  EvEnements. 

Pannes  en  fin  d'utilisatlon 

Cette  procEdure  permet  de  foumir  E 
I'opErateur  la  llste  des  Equipements  encore 
en  panne  au  moment  de  I'arrEt  de  I'enregis- 
trement.  Ces  Equipement  dont  classes  en 
deux  listes  : 

•  Ceux  qui  sont  en  panne  avec  localisation 
sure  :  ces  equipement  peuvent  Eire  rem- 
placEs  ImmEdiatement,  sans  recherche 
complementaire. 

•  Ceux  qui  sont  en  panne  avec  localisation 
amblgua  ;  ces  Equipements  demandent 
une  recherche  complEmentaire  afin  de 
dEterminer  qu'elle  est  I'URL  en  dEfaut  E 
remplacer.  C'est  pour  ce  type  de  panne, 
entre  autres,  que  I'on  fait  appel  E  la  main¬ 
tenance  complEmentaire  au  sol. 

Les  enregistrements  sont  effectuEs  dans  une 
zone  mEmoIre  non  volatile  E  bord  de  I'avion 
afin  que  ces  informations  pulssent  Etre  relues 
et  exploitEes  mEme  aprEs  mise  hors  tension 
de  I'avion.  A  chaque  nouveau  vol,  les  enre¬ 
gistrements  du  vol  prEcEdent  sont  effacEs. 

Hlstorlque  des  EvEnements : 

II  permet  de  restituer  la  chronologle  des 
EvEnements  survenus  et  enregIstrEs  pendant 
rutlllsation  opEratlonnelle.  Son  exploitation 
peut  ; 

•  permettre  de  comprendre  certains  phEno- 
mEnes  par  la  connaissance  de  I'enchal- 
nement  de  ceux-cl. 
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•  permettre  de  connattre  les  6v6nements 
fugitifs  ;  pannes  qui  sent  apparues  puis 
disparues  at  ne  sont  done  plus  pr^sentes 
au  retour. 

5.1 .1 .2  LES  COMPTES-RENDUS  INSTAN- 
TANE8  (CRI) 

Cette  procedure  utilise  exactement  les 
mdmes  contrdles  que  ceux  effectu^s  pour  les 
comptes  rendus  enregistrds.  La  difference 
reside  dans  le  fait  qu'il  n'y  a  pas  de  memori¬ 
sation,  mais  presentation  en  temps  reel  e 
I'operateur  des  resultats  des  tests.  Celui-ci 
peut  done  voir  evoluer  le  fonctlonnement  des 
equipements  du  point  de  vue  des  autotests 
permanents. 

C'est  cette  procedure  qui  est  utlllsee 
pour  valider  une  reparation  quand  un  equi- 
pement  a  ate  remplace  suite  e  I'exploitation 
des  pannes  en  fin  d'utllisatlon. 


5.1.2.  ORGANISATION  DES  ECHANGES 
D'INFORMATIONS 

Chaque  equipement  envois  sur  le  bus 
numerique  multiplexe  un  message  dit  de  ser¬ 
vitude  qui  comprend  ; 

•  Un  mot  de  panne  constitue  d'un  nombre 
entier  d'oetets,  le  format  etant  unique 
pour  un  sous-systeme  donne.  Ce  mot  de 
panne  foumit : 

•  Une  indication  de  bon  fonctlonnement 
global  de  I'equipement  ou  une  Indica¬ 
tion  de  bon  fonctlonnement  par  URL 
dans  le  cas  d'^uipements  multi-URL. 

•  Une  Indication  de  bon  fonctlonnement 
pour  chacune  des  entit^s  fonction- 
nelles  de  chaque  URL  constituent 
I'equipement. 

•  Un  mot  de  mode,  qui  foi'-  ilt  I'IndIcation 
du  mode  dans  lequel  I'SquIpement  fonc- 
tionne  dans  le  cas  des  equipements  multi¬ 
modes. 

•  Un  mot  d'Etat  Interne,  qui  foumit  pour 
chaque  URL  constituent  I'equipement : 

•  Une  Information  de  panne  par  URA 
constituant  I'URL 

•  Une  information  de  resultat  bon  ou 
mauvais  de  chaque  auto-test  eiemen- 
talre  execute  dans  I'equipement. 

II  y  a  done  autant  de  Mots  d'Etat  Internes 
qu'll  y  a  d'URL  dans  un  equipement.  Ce  dls- 
posKlf  permet  de  faire,  an  ligne,  un  diagnos¬ 
tic  d’URA  en  panne,  par  la  maintenance 
temps  reel. 

•  Un  mot  d'Atarme.  qui  permet  de  faire 
apparattre  au  pilote  une  alaime  et  Sven- 


tuellement  une  consigne,  en  cas  de  panne 
detectee. 

Cet  ensemble  d'Informatlons  est 
envoye  sequentiellement  (toutes  les  160 
ms  environ)  vers  I'organe  de  calcul  cen¬ 
tralise  pour  etre  traite. 

Chaque  information  transmise  par  un 
equipement  par  I'intermediaire  du  messa¬ 
ge  de  servitude  doit  etre  consolidee  et  fil- 
tree  au  niveau  de  chaque  equipement 
avant  d'etre  transmise. 

Au  niveau  global,  ces  informations 
sont  traitees  afin  de  constituer  les 
Comptes-Rendus  de  Maintenance  (CRM). 

Chaque  CRM  comprend  : 

•  Un  mot  de  panne  globalise  h  partir 
des  informations  du  mot  de  panne  de 
I'equipement. 

•  Un  mot  de  mode 

•  Un  mot  d'Etat  Interne 

•  Un  mot  d'IdentIficatlon 

•  Un  mot  de  datatlon.  (resolution  Infe- 

rieure  k  200  ms). 

5.1.3.  ORGANISATION  DU  TRAITEMENT 
GLOBAL  (VOIR  FIG.1) 

Toutes  les  informations  contenues  dans 
les  messages  de  servitude  sont  tout  d'abord 
traitees  dans  un  module  de  traitement  appeie 
'Flltrage  Inter-systeme".  Cette  fonctlon  a 
pour  but  de  rechercher  les  evenements  k 
I'origine  d'un  mauvais  fonctlonnement  afin  de 
detecter  la  panne  et  la  separer  de  ses  conse¬ 
quences. 

La  sortie  de  cette  fonctlon  est  reliee  a 
trois  autres  qui  sont  ; 

•  Les  modules  lies  k  I'eiaboration  des  alar- 
mes  pilotes  et  des  consignes  associees 

•  Les  modules  lies  k  la  gestlon  des  modes 
degrades 

•  tee  modules  lies  k  la  generation  des  dia¬ 
gnostics  de  pannes  pour  remise  en  etat 
par  le  mecanicien. 

A  I'heure  actuelle,  tous  les  trai- 
tements  sont  algorithmiques,  mais  nous 
avons  entrapris,  dans  le  cadre  d'une  etu¬ 
de  'co-pllote  eiectronique',  la  resolution 
d'un  certain  nombre  de  fonctlons  par 
Intelligence  Artificlelle.  Les  fonctlons  etu- 
diees  sous  cet  aspect  sont  ; 

>  Le  fittraga  Inter-systemes 

■  Les  modules  lies  k  la  generation  des 
alarmes  et  des  consignes  pilote 

•  La  gestlon  des  modes  degrades. 
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Les  principaux  probl^mes  rencontres 
concement  principalement,  le  temps  de 
reponse  qui  doit  Mre  tres  proche  du  temps 
rtel  car  lie  e  la  securite  du  vol.  A  I'heure 
actuelle,  le  temps  de  reponsa  en 
algortthmlque  est  de  I'ordre  de  400  e  500  ms. 
Le  second  probieme  correspond  k  la  tallle 
des  logiciels  k  embarquer  ainsi  qu'e  la  puis¬ 
sance  de  calcul  requise. 

Lorsque  ce  probieme  sera  resolu,  II  sera 
alors  possible  de  resoudre  de  la  memo 
maniera  les  logiciels  de  traitement  des  dia¬ 
gnostics  de  pannes  quI  ont  au|ourd'hui  des 
temps  de  reponse  homogenes  avec  les  alar- 
mes  pllote,  c'est-A-dlre  de  I'ordre  de  400  e 
500  ms. 

L'approche  globale  developpee  montre 
que  nous  avons  le  maximum  de  garanties 
d'homogeneite  entre  toutes  ces  fonctions 
Vitales,  car  eiabordes  e  partir  de  donnees 
identiques  et  formallsees  de  fapon  homogene 
entre  tous  les  dqulpements  et  systemes  de 
I'avion. 

Ou  point  de  vue  des  performances,  la 
maintenance  Integree  aujourd'hui  permet 
d'avoir  un  diagnostic  non  ambigO  dans  70% 
des  cas  de  panne  au  niveau  des  URL  avec  un 
taux  de  fausse  depose  interieur  k  10%.  L'ap- 
port  de  rintelligence  artificlelle  devrait  nous 
faire  atteindre  un  taux  de  bon  diagnostic  de 
I'ordre  de  80  k  85%  avec  un  laux  de  fausse 
depose  Inferieur  e  5%. 

Le  diagnostic  d'URA  en  panne  par  la 
maintenance  Integree  temps  reel  se  situe  aux 
environs  de  30  e  40%  des  cas  :  ce  pourcenta- 
ge  devrait  etre  sensiblement  ameiiore  par 
I'utillsatlon  de  rintelligence  artificlelle. 

Compte  tenu  des  contraintes  temps  reel 
extremernent  severes  pour  ces  functions  exe- 
cutees  pendant  le  fonctlonnement  operation- 
nel  de  I'avion,  nous  ne  pensons  pas  faire 
voler  en  experimentation  un  systeme  base 
sur  t’intelligence  artificlelle  avant  1998. 

S.2.  MAIHTENANCE  COMPLEMENTAIRE 
AU  SOL. 

Ella  a  pour  ob|et  de  permettre  la  locali¬ 
sation  de  pannes  lorsque  la  maintenance 
temps  reel  n'a  pas  ete  en  mesure  de  le  faire. 

En  eftat,  pendant  la  fonctlonrrement  opd- 
rationnel  d'un  dquipement  ou  systems,  II 
n'est  pas  envisagaable  do  realisar  les  tests 
contpiemantalrm  parturtianls  qui  permettent 
de  tocaliser  las  pannes  de  ta^n  exhaustive. 

Ces  contrOles  compiementaires,  effec- 
tuds  au  sol,  peuvent  dire  des  lasts  ddclen- 
chds,  das  pi^lormements  d'infbrmations  d 
das  valeurs  llxdas,  ou  des  laclurss  de  valeurs 
d'lnformaMona  rogues  ou  dmisos  par  les  dqul- 
pemenls. 


Afin  de  faclilter  la  tdche  de  I'opdrateur  et 
de  diminuer  les  durdes  de  contrOles,  les 
dquipements  ou  les  systdmes  dont  la  techno- 
logle  le  permet,  abandonneni  le  fonctlon¬ 
nement  opdratlonnel  au  profit  d'un 
fonctlonnement  adapid  d  la  localisation  de  la 
panne  et  la  vdrificatlon  des  didments  consti- 
tuant  I'dquipement  ou  le  systdme.  Oe  plus,  la 
malnterrance  compidmentaire  au  sol,  comme 
son  nom  I'lndlque,  est  un  compidment  k  la 
maintenance  temps  rdel  et  ne  remet  pas  en 
cause  les  rdsultats  obtenus  par  celle-ci. 

Pour  une  rttaintenance  rapide  et  efficace, 
les  contrOles  relatifs  d  la  vdrificatlon  du  bon 
dtat  d'un  dquipement  se  font  par  un  contrOle 
de  I'intdgritd  matdrielle  des  composants,  par 
vdrificatlon  de  I'intdgritd  du  logiclel  et  non 
par  simulation  de  fonctlonnement.  Des  tests 
correctement  rdallsds  sur  le  logiclel  d'un 
dquipement  valldent,  d  priori,  compidtement 
ce  logiciel. 

Dans  ce  mode,  la  maintenance  fournit  a 
I'opdrateur  un  ensemble  d'outlls  que  celul-ci 
utilise  d  sa  convenance.  Dans  ce  cas,  la  loca¬ 
lisation  de  panne  est  le  resultat  de  la 
rdflexion  de  I'opdrateur  utilisant  ces  outils, 
dventuellement  assistd  par  des  logiciels  auto- 
matiques  ou  semi-automatiques. 

A  ce  stade,  il  est  dvideni  qu'un  systeme 
expert  peut  dtre  d'une  grande  utilitd. 


S.2.1.  FONCTIONNEMENT  DE  LA 
MAINTENANCE  COMPLEMENTAIRE 

La  maintenance  compidmentaire  au  sol  a 
pour  but  de  foumir  d  I'opdrateur  les  moyens 
d'ivestigation  ndcessaires  d  I'identiflcation  de 
I'dldment  en  ddfaut  dans  le  cas  des  pannes 
de  localisation  ambigOe.  Les  pannes  de  loca¬ 
lisation  ambigOe  sont  celles  qui  mettent  en 
cause  plusleurs  URL  et  pour  lesquelles  il  n'a 
dtd  possible,  en  temps  rdel,  que  de  ddtecter 
une  anomalle  au  niveau  d'une  fonction,  mats 
sans  pouvoir  effectuer  la  localisation. 

De  prime  abord,  les  dispositifs  mis  en 
oeuvre  par  la  maintenance  compidmentaire 
au  sol  vont  foumir  des  points  d'accds  inter- 
mddlaires  d  I'lntdrteur  des  fonctions  de 
manidre  d  permettre  la  localisation.  Ces 
points  Intermddiaires  et  les  dispositifs  corres- 
pondants  vont  permettre  ; 

•  de  lire  des  Informations  en  ces  points 

•  de  positlonner  ces  Informations  d  dlffd- 
rentes  valeurs 

•  de  ddclencher  des  tests  perturbants 

•  etc 

La  mise  en  oeuvre  de  ces  dispositifs 
peut  Mrs  effectude  selon  les  cas  par  les 
moyens  sulvants  : 


•  Manuellement  par  I'opirateur  (ce  qui 
requtart  de  sa  part  une  bonne  connais- 
sance  du  foncttonnement  de  la  mainte¬ 
nance  Int^r^e  alnsi  que  des  systtimes  a 
contrdler) 

•  Manuellement  par  I'op^rateur,  mats  assis¬ 
ts  par  des  'outils  loglclels" 

•  Automatiquement  par  des  programmes  de 
test  et  de  contrdle 

Pour  certalnes  utilisations  ou  fonctions,  il 
est  possible  d'automatiser  I'utlllsation  de 
la  maintenance  compMmentaire  au  sol,  au 
moyen  de  loglclels  spteiflques  charges 
temporairement  dans  I'organe  de  calcul 
central  g^rant  la  maintenance. 

Ces  loglclels  sont  nAcessaires  dans  les 
cas  suivants  : 

•  lorsque  la  steuriti  est  en  jeu  et  que  des 
contrdles  stricts  sont  nAcessaires 

•  lorsque  les  paramMres  il  manipuler  sont 
soit  trop  rapides,  soit  trop  complexes  et 
done  incompatibles  avec  une  exploitation 
manuelle. 

On  est  aussi  amen^  ii  utlllser  la 
maintenance  compl^mentalre  au  sol  lors¬ 
que  le  pllote  signale  une  anomalie  et 
qu'aucune  trace  n'est  prAsente  dans  les 
Comptes  Rendus  de  Maintenance. 

S.2.2.  CONTROU  DES  INTERFACES  ET 
DE  U  CONTmUITE  DES  LIAISONS 

Les  Aquipements  et  les  systimes  sont  de 
plus  en  plus  numirisAs  et  InformatisAs.  Ce 
type  de  technologle  est  partlcull^rement  bien 
adapts  k  la  maintenance  IntAgrAe.  En  eftet, 
avec  ce  type  d'^uipement.  II  est  possible  de 
sAparer  le  contrAle  en  deux  parties  indipen¬ 
dant  es. 

•  d'une  part  le  contrOle  de  I'Intigriti  du 
loglclei  d'applicatlon 

•  d'autre  part  le  contrdle  de  I'intigriti  de 
chacun  des  composants  de  I'iqulpement. 

Si  ces  opirations  sont  correctement 
monies,  elles  suffisent  i  valider  le  bon 
fonctionnement  da  I'iquipement,  et  pour 
une  grande  part  en  temps  riel,  pendant  le 
fonctionnement  opiratlonnel. 

Le  point  falble  sur  le  plan  da  la  loca¬ 
lisation  de  panne  itant  lea  Interfaces,  le 
cibtage  et  les  capteurs,  la  maintenance 
complitnentalrv  va  done  Wre  ortentie 
essanHellemanI  vers  la  viiWcallon  des 
iMments  constHuant  cos  circuits  et  le 
contrile  des  liaisons. 

■  Cas  des  Informations  recues  par  un 
iqulpement : 


Un  iqulpement  numirique  qui  recoil 
des  paramitres  analogiques  doit 
d'abord  les  convertir  sous  forme 
numirique  avant  de  pouvoir  les  uflll- 
ser  dans  ses  algorithmes  :  il  en  risul- 
te  done  que  son  circuit  de  riception 
se  comporte  comme  un  appareil  de 
mesure. 

•  Cas  des  Informations  imises  par  un 
iqulpement : 

Un  iqulpement  numirique  qui  fournit 
des  paramitres  analogiques  dolt 
d'abord  calculer  la  valeur  en  numiri¬ 
que  au  cours  de  son  traltemeni,  puis 
convertir  ce  paramitre  sous  forme 
analogique  ;  il  se  comporte  done  com¬ 
me  un  appareil  de  giniration  de 
signal. 

Pour  virifier  une  liaison  analogi¬ 
que,  il  suffit  de  faire  en  sorte  que  les 
valeurs  imises  par  un  iqulpement 
source  puissent  itre  fixies  par  I'opi- 
rateur  et  que  celles  repues  par  I'iqui- 
pement  destinataire  soient  prisenties 
i  I'opirateur,  afin  que  celui-cl  puisse 
juger  de  la  qualiti  de  la  liaison.  Avec 
un  rebouclage  de  la  sortie  de  I'iqui¬ 
pement  imetteur  sur  un  de  ses 
codeurs  d'entree,  il  est  possible  de 
virifier  que  la  valeur  imise  est  bien 
conforms  i  la  valeur  de  position- 
nement,  et  done  de  rialiser  la  locali¬ 
sation  de  la  panne. 

5.2.3.  ORGANISATION  GENERALE  DE  LA 
MAINTENANCE  COMPLEMENTAIRE 

L'ensemble  des  traitments  liis  i  la  main¬ 
tenance  complimentaire  au  sol  est  assuri 
par  le  calculateur  qui  centralise  la  gestion  de 
la  maintenance.  Ce  calculateur.  pour  cette 
fonctlon,  interface  I'opirateur  i  l'ensemble 
des  systimes  de  I'avion.  Le  dialogue  avec 
I'opirateur  s'effectue  soit  par  I'Intermidiaire 
des  commandes  et  visualisation  du  cockpit 
qui  sont  alors  spiclalement  configuries  pour 
ce  fonctionnement,  soit  par  I’Intermidiaire 
d  un  posts  spiciflque  accessible  depuis  le 
sol,  soit  iventuellement  par  un  ensemble  de 
dialogue  diporti  et  relii  au  bus  avion  par 
une  prise  coque.  (voir  FIG.2). 

Le  fonctionnement  maintenance  compli¬ 
mentaire  au  sol  mettant  en  |eu  dans  la  plu- 
part  des  cas  un  nombre  relativement 
important  d'iquipements,  n'est  pas  utllisi 
pour  la  localisation  d'URA  en  panne  afin  de 
ne  pas  pinaliser  la  fiablliti  globale  de 
I'avion. 

Ce  mode  de  fonctionnement  est  aujour- 
d'hul  entlirement  algorlthmique.  Cependant, 
il  est  particullirement  bien  adapti  k  I'lntelll- 
gence  artificlelle  du  fait  qu'il  n'y  a  prati- 
quement  pas  de  contrainte  temps  riel.  Les 


21-8 


logiclels  du  systAme  expert  alnsi  que  les 
bases  de  donn^es  peuvent  Mre  charges  dans 
le  calculateur  hdte  A  la  place  du  logiclel  opA- 
ratlonnel  puisque  celul-ct  n'est  pas  utilise  en 
maintenance  compl6mentaire  au  sol.  Par 
ailleurs,  le  dialogue  avec  I'op^rateur  est 
extrAmement  rMult  du  fait  que  les  actions  de 
test  et  leurs  rtoultats  sont  entiirement  g^r^s 
informatiquement  par  rintermMlaire  de  la 
fonction  gestlon  de  la  maintenance  compli- 
mentaire.  Les  dichotomies  peuvent  Mre 
effectutes  automatiquement  et  les  actions  de 
test  suivantes  automatiquement  cholsles  et 
dtelench^es  par  le  syst^me  expert  en  (onc- 
tion  des  regies  dAfinles.  Le  rdle  de  I'op^- 
rateur  est  par  le  fait  mAme  extrAmement 
r^duit  et  pratiquement  limits  k  la  description 
des  symptdmes  vus  par  ie  piiote. 

(voir  FiG.  3). 

A  i'heure  actueile,  on  considers  que  ia 
maintenance  compi^mentaire  au  soi  permet 
de  compIMer  ies  performances  de  ia  mainte¬ 
nance  temps  rdei  pour  obtenir  un  laux  giobai 
de  iocaiisation  d'URL  en  panne  de  95%.  La 
rapidity  du  test  et  son  efflcaciti  sont  fonction 
de  ia  quaiit6  de  i'opArateur  en  utiiisation 
manueiie.  On  considire  que  dans  ce  mode, 
environ  95%  des  dMauts  sont  iocaiis^s  en 
moins  de  deux  heures  par  un  micanicien  de 
bon  niveau,  ii  faut  en  outre  remarquer  que 
les  validations  de  chalnes  fonctlonnelles  d'ar- 
mement  sont  toutes  effectu^es  automati¬ 
quement  d  I'alde  de  logiclels  g^rant  les 
procedures  Les  performances  actuelles  mon- 
trent  que  la  validation  d  une  configuration 
d'emport  quelle  qu'elle  soil  dure  largement 
moins  d  une  heure. 

L'apport  de  rintelllgence  artificlelle  dans 
ce  cas  peut  Mre  Interessant  pour 
homogenMser  les  resultats.  II  serait  envl- 
sageable  de  considerer  qu'une  action  de  dia¬ 
gnostic  quelle  qu'elle  solt  dans  ce  mode  dure 
moins  d'une  heure  avec  une  efflcacItA 
mellleure  que  95%  des  cas  de  panne  (taux 
de  fausse  depose  InfArieur  h  5%).  Par 
ailleurs,  le  niveau  de  formation  des  micani- 
ciens  pourralt  Mre  blen  InfArteur  A  ce  qui  est 
demand  A  aujourd'hui. 

Le  dMreloppement  de  ce  type  de  syst^ 
me  expert  n'est  encore  pas  entreprls  fi  I'heu- 
re  actueile  car  le  bien  fond4  ^nomique  de 
ce  d^veloppement  n'est  pas  encore  d^montri 
compte  tenu  des  performances  attertdues  de 
la  malnteiMince  temps  rdel  d'une  part,  at  de 
I'efflcacM  des  tests  rAallsds  de  fa^on 
algorlthmique  observAe  (usqu'li  mainterwnt.  II 
faudra  attetKfre  encore  1  an  ou  2  d'essals  en 
vol  avaiTt  de  preitdre  un  decision. 


6.  MAMTIIIANCi  HORS  UONI 

La  malnisnanca  hors  ligna  oat  renaam- 
Me  dao  opMstlona  da  ntaIntanaiKa  axMiutMis 


par  les  Mihelons  de  soutien  technique  des 
utilisateurs. 

Le  but  de  la  maintenance  hors  ligne  est 
d'assurer  le  d5pannage  et  le  contrdle  des 
URL.  Les  URL  sont  dteomposfo  en  URA  qui 
sont  des  6l5ments  Interchangeables  au 
niveau  de  I'ateller  hors  ligne.  De  mAme  que 
la  maintenance  en  ligne  a  pour  ob|M  le  main- 
tlen  en  condition  do  I'avlon,  la  maintenance 
hors  ligne  a  pour  objet  le  maintlen  en  condi¬ 
tion  des  URL. 

La  maintenance  hors  ligne  s'offectue  en 
atelier  et  nM:e8site  la  mise  en  oeuvre  de 
moyens  mat6iiels  et  logiclels.  (Ces  moyens 
sont  gAnMalement  foumis  par  un  moyen  de 
test  h  caract5re  universel).  Elle  s'applique  i 
rURL,  et  porte  sur  la  dMectlon  M  la  locali¬ 
sation  de  I'URA  en  panne,  sans  Intervention 
de  I'op^rateur  au  sein  de  I'URL  pour  le 
contrdle  de  bon  fonctionnement  ;  dven- 
tuellement  avec  accds  d  un  connecteur  inter¬ 
ne  d  I'URL  pour  les  contrdles  compldmen- 
talres  de  localisation  d'avarle. 

Les  rdparations  doivent  s'effectuer  par 
ddpose/pose  de  I'URA  en  panne  d  I'alde 
d'outillages  standard  excluant  le  fer  d  sou- 
der. 

II  faut  noter  que  comme  pour  la  mainte¬ 
nance  en  ligne,  la  maintenance  hors  ligne  est 
basde  sur  les  principes  de  maintenance  intd- 
grde,  c'est-d-dire  vdrification  de  I'dqulpement 
par  contrdle  de  I'intdgritd  des  composants 
plutdt  que  par  simulation  de  fonctionnement, 
et  ceci  d  cheque  fois  que  cela  est  possible,  en 
tenant  compte  de  la  technologie  des  URL  et 
des  URA.  Le  but  est  bien  dvidemment  de 
rdduire  les  temps  de  rdparatlon  d'une  URL  et 
par  vole  de  consdquence,  limiter  I'occupation 
du  banc  de  test  pour  les  opdratlons  effec- 
tudes  sur  une  URL  donnde.  Dans  ce  mdme 
but,  on  profitera  des  rdsultats  foumis  par  la 
maintenance  en  ligne  pour  accdidrer  les  opd- 
rations  en  atelier,  notamment  en  dvitant  de 
refaire  des  autotests  ddfd  rdalisds  sur  avion. 

6.1.  PRINCIPE 

Les  procddures  de  test  sont  habituellement 
articuldes  en  : 

•  Test  de  bon  fonctionnement 

•  Test  de  localisation  d'avarle 

•  Le  test  de  bon  fonctlonttement  a  pour  but 
de  vdrifier  I'intdgritd  du  matdriel  M  du 
logiclel  de  I'dqulpement.  II  est  rdallsd  sur 
une  URL  pour  vdrifier  son  bon  fonction¬ 
nement  solt  aprds  destockage,  solt  pour 
dMecter  la  fonction  en  panne  afin  d'al- 
gulller  le  programme  de  test  vers  la  loca¬ 
lisation  d'avarle  addquate.  II  peut 
dgalemenl  Mre  rdallsd  en  Meller  aprds 
rechargement  du  logiclel  dO  d  un  chan- 
gement  da  standard. 


•  Le  test  de  localisation  d'avarie  a  pour  but 
de  localisar  pr^is^ment  I'avarie  «t  done 
en  dMuIre  qu'elle  est  I'URA  en  panne 
qu'll  faut  remplacer. 

En  fait,  catte  separation  n'est  plus 
celle  utilisee  aujourd'hui.  Cbaque  equi- 
pement  est  decompose  en  Ensemble  de 
Composants  Testables  par  la  methode 
d'integiite.  Chaque  test  d'Ensemble  de 
Composants  Testables  fait  Toblet  d'un 
chapttre  de  test  qui  verifie  soit  le  bon 
fonctlonnement  (bonne  Integrite),  soit 
detects  la  panne  et  la  localise  au  niveau 
d'une  URA. 

6.2.  MODE  OPERATOIRE 

Les  equipements  sont  testes  au  niveau 

de  I'atelier  hors  ligne  dans  les  cas  suivants  ; 

•  Lorsque  I'URL  a  ete  deteetde  en  panne 
sur  avion  par  la  maintenance  temps  reel 
et  que  I'URA  fautive  est  parfaltement  loca- 
lisee  (par  lecture  du  mot  d'Etat  Interne 
par  exemple).  Dans  ce  cas,  les  operations 
sont  ; 

•  Remplacement  de  I'URA  fautive  dans 
I'URL  (II  n'est  pas  necessaire  de 
confirmer  la  panne) 

•  Contrdle  de  I'URL  reparee  par  une 
verification  de  bon  fonctlonnement 

•  Lorsque  I'URL  a  ete  detectee  en  panne 
sur  avion  par  la  maintenance  temps  reel 
mais  sans  localisation  sCire  de  I'avarie. 
Dans  ce  cas.  les  operations  sont : 

•  Lecture  du  Mot  d'Etat  Interne  et  utili¬ 
sation  des  resultats  de  la  maintenance 
en  ligne  pour  orienter  le  programme 
de  test  vers  le  chapitre  correspondant 
e  la  fonction  en  defaut.  (II  n'est  pas 
necessaire  de  confirmer  la  panne  par 
le  passage  en  verification  de  bon 
fonctlonnement.  car  celle-ci  a  ete 
detectee  par  les  autotests  ;  il  ne  sub¬ 
sists  qu'un  problems  de  localisation 
et  on  utilise  les  resultats  des  tests 
temps  reel  pour  aller  rapidement  vers 
le  chapitre  de  test  qui  localisera  la 
panne). 

•  Apres  localisation  de  I'avarie  :  rem¬ 
placement  de  I'URA  fautive 

•  Contreie  de  I'URL  reparee  par  une 
verification  de  bon  fonctlonnement 
global. 

•  Lorsque  I’URL  a  ete  detectee  en  panne 
sur  avion  au  moyen  de  la  maintenance 
compMmentalre  au  sol,  gendralement, 
dans  ce  cas,  la  localisation  n'est  pas 
assures  et  on  se  retrouve  done  ramend 
au  cas  precedent,  k  la  difference  que  le 
Mot  d'Etat  Interne  ne  foumit  pas  de  ren- 


seignement  precis.  Si  les  informations  de 
la  maintenance  compldmentaire  le  per- 
mettent,  on  oriente  le  programme  vers  le 
chapitre  convenable  du  programme,  slnon 
on  utilise  la  verification  du  bon  fonction- 
nement  qui  assurera  i'orlentation  vers  ie 
chapitre  ou  la  panne  pourra  etre  localisde 
en  fonction  des  rdsultats  des  contrdles 
effectuds. 

6.3.  FONCnONNEMENT  DES 
PROCEDURES  DE  TEST  (FI0.4) 

Les  procedures  de  test  de  maintenance 
hors  ligne  sont  entidrement  gdrdes  par  un 
mdeanisme  appeld  'Mdeanisme  de  Decision', 
dont  les  fonctions  sont  les  sulvantes  ; 

•  Gestion  de  la  'mise  en  place'  de  I'URL 
sous  test  sur  le  testeur 

•  Analyse  des  donndes  foumies  par  les 
donndes  de  maintenance  integrde  temps 
reel  au  niveau  avion  et  en  parliculier  le 
Mot  d'Etat  Interne 

•  Eventuellement  analyse  du  Mot  d'Etat 
Interne  instantand  de  I'URL  sous  test 

•  Eventuellement  analyse  des  donndes 
foumies  par  la  maintenance  compldmen- 
taire  au  sol  (soit  par  I'intermddiaire  de 
I'opdrateur.  soit  d  partir  d’une  base  de 
donndes  en  provenance  de  la  maintenan¬ 
ce  en  iigne). 

•  Ddcislon  sur  I'exdcution  du  chapitre  de 
test  le  plus  pertinent  en  fonction  des 
rdsultats. 

•  Exdcution  dventuelle  d'autre  chapitres  en 
fonction  des  rdsultats  foumis  par  les 
chapitres  prdeddents.  en  tenant  compte 
des  donndes  de  fiabllitd.  de  la  facilitd 
relative  des  ddposes  d'URA,  etc. 

•  Etablissement  du  diagnostic 

•  Aprds  dchange  de  I'URA  fautive.  gestion 
de  I'exdcution  du  test  de  bon  fonction- 
nement 

•  Elaboration  d'une  base  de  donndes  perti- 
nentes  pour  la  maintenance  industrlelle 

Ce  mdeanisme  d'exdcution  sera  rdalisd  pour 
le  test  des  dquipements  RAFALE  par  un  sys- 
tdme  expert  implantd  dans  le  testeur. 

L'utillsation  de  ce  principe,  llde  d  I'appllca- 
tlons  la  plus  extensive  possible  du  test  d’intd- 
gritd  permet  d'envisager  un  temps  moyen 
d'lmmobillsation  du  testeur  infdrteur  d  1  heu- 
re  pour  la  remise  en  dtat  d'une  URL. 


7.  MAmTENANCE  MIHISTRIELLE 

La  maintenance  industrlelle  est  I'ensem- 
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ble  des  operations  permettant  la  localisation 
d'un  composant  ddfectueux  d'une  URA  et  son 
echanga. 

Las  moyans  nicessalras  e  la  localisation 
du  composant  detsctuaux  d'une  URA  sont  an 
general  das  t>ancs  da  test  automatises. 

Tout  ce  qui  a  ete  developpe  au  paragra- 
pha  6  concamant  la  maintenanca  hors  ligna, 
peut  s'appliquar  da  la  mema  maniera  e  la 
maintananca  Industrialla.  Las  donneas 
amont  da  ca  nivaau  da  maintanance  sont 
foumlas  par  la  tastaur  da  maintanance  hors 
llgne  et  eventuallemant  las  donneas  extraltes 
da  I'avion  et  confactionneas  par  la  mainte¬ 
nance  en  llgne  temps  real. 

Aujourd'hui,  la  decision  d'appliquer  A  la 
maintenance  Industrialla  un  'Mecanisme  de 
Decision"  du  mAme  type  qua  celul  de  la 
maintenance  hors  llgne.  n'a  pas  encore  ete 
prise. 

8.  DEVELOPPEMENT  DES 
TECHNIQUES  01NTELLIOENCE 
ARTIFICIELLES  APPUQUEES  A  LA 
MAINTENANCE  TEMPS  REEL 

Las  actions  maneas  par  requipa  d'Appll- 
cation  de  rintelllgence  Artiflclelle  de  la  Divi¬ 
sion  Systemas  d'Armes  s'Inscrivent  dans  la 
cadre  d'un  profet  ambitieux  d'assistanca  au 
pilote  appaie  'Copilota  Elactroniqua". 

Ce  projat  lance  en  1986  par  la  DRET  et 
contorte  par  la  SITE,  visa  e  utlllser  I'lA  pour 
reaiisar  un  systema  d'aida  i  la  decision, 
ambarque  dans  un  avion  monoplace  de  com¬ 
bat.  L'objactif  ast  da  foumir  au  pilota  des 
informations  partinantes  pour  aider  e  la  deci¬ 
sion. 

La  contaxta  tamps  real  ambarque  Intro- 
dult  de  nombreuses  speciflcites  tant  theoii- 
quas  qua  pratiques,  quI  necassltant  une 
demarche  origlnale  vis-A-vIs  des  solutions 
classiques  de  diagnostic  hors  llgne. 

Gael  nous  a  amane  e  etudlar  avac  la 
societe  DASSAULT  ELECTRONIQUE  las  fllie- 
ras  d'ambarquablllte  da  systems  d'lntelll- 
genca  ArtHIclalle  dans  la  domalna  du  flitraga 
d'atarmas.  (etuda  STTE  'Maquatta  da  Syste¬ 
ma  Expart  Embarquabla  sur  Avions  d'Armas". 

II  s'agIssM  ; 

•  da  prouvar  la  fatoabitlte  da  I'atnbarqua- 

blllte  d'un  systema  axpart  avioniqua  sur 

une  appfteation  rapresantatlva 

•  da  propoaar  una  IHiera  (maMriaNa  at  logl- 

daUa)  pour  la  devatoppomant  d'un  tal 

systema. 


Las  contraintes  de  prise  en  compte  du 
temps  d'lntarruptlblllte  des  traitements, 
d'asynchonisme  des  arriveas  d'informations 
et  de  limitation  des  volumes  memoira,  ont  ete 
couvertes  de  maniera  i  pouvoir  dlmension- 
ner  las  puissances  de  calcul. 

Ces  premiers  elements  de  chIfTrage  obte- 
nus  pour  un  flitraga  d'alarmas  multlsystemas 
(motaur,  eiactrlcite,  hydraullque  et  freinage) 
au  regard  des  materials  compatibles  du 
RAFALE  A,  nous  ont  amenes  A  envisager 
avec  DASSAULT  ELECTRONIQUE,  une  appro- 
che  de  devaloppament  sur  un  generataur  de 
systeme  expert  riche,  complete  par  une  tra¬ 
duction  vers  un  langage  de  production  de 
logiciel  embarque  (ADA).  L'optimisation 
temps  reel  de  certaines  fonctions  peut  etre 
obtenue  en  dediant  le  traducteur  e  un  type 
d'application  precis  (i.e.  le  filtrage  d'alarmes 
inter-systemas). 

Nous  nous  proposons  d'etudier  cette 
approche  pour  I'avion  RAFALE  et  un  calcu- 
lateur  type  CMF-air. 

En  paralieia  de  cette  demarche  sur  la 
flliere  de  traduction  vers  ADA.  Nous  tra- 
vaillons  au  devaloppemant  des  fonctions 
d'assistanca  en  matiera  de  surveillance  des 
systemas  de  I'avion,  de  reconfiguration  apres 
pannes,  de  filtrage  d'alarmes  et  d'execution 
de  procedures  d'urgences. 

Avec  la  societe  SAGEM,  nous  preparons 
des  travaux  qui  permettront  de  diagnostiquer 
les  pannes  simples  puis  las  pannes  multiples, 
de  maintenir  un  vectaur  d'etat  generalise,  et 
de  proposer  au  pilote  des  reconfigurations 
liees  au  contexts  de  la  mission. 

Les  traitements  d'Intelllgence  Artiflclelle 
permettent  une  reflexion  sur  les  donnees  bru¬ 
tes  circulant  sur  les  bus,  grdee  i  la  mainte¬ 
nance  integrea  alnsi  qua  des  predictions  sur 
les  evolutions  das  systemas  (disfonc- 
tionnaments  probables,  derives...).  Alnsi  une 
estimation  de  la  capacite  de  I'avion  i  remplir 
sa  mission  sera  rendue  possible. 

Css  traitements  mattront  en  oeuvre  des 
techniques  symbollques  de  diagnostic  par 
regies  expertes  combineas  e  des  algorithmes 
de  traitamant  du  signal,  des  techniques  de 
programmatlon  declarative  en  langage  orien- 
te  objet,  de  gestlon  d'hypothesas  et  de  pro¬ 
grammatlon  sous  contrainta  pour  la  pla- 
niflcation  das  reactions. 


9.  DEVELOPPEMENT  DES 
TECHNIQUES  DINTELUGENCE 
ARTIPICKLLE  APPUQUEES  AU 
DMONOSne  DE  PANNES  HORS 
TEMPS  REEL 


L'exp6rlence  du  Depariement  Intelli¬ 
gence  Artificlelle  de  DASSAULT  AVIATION 
dans  le  domaine  du  diagnostic  de  pannes  a 
6t6  obtenue  i  travers  deux  projets  : 

•  Une  dtude  effectu^e  en  collaboration  avec 
ALCATEL  ALSTHOM  sous  conlrat  DRET  et 
concernant  une  tonctlon  du  syst^me  d'ar- 
mes  du  MIRAGE  FI. 

•  Une  6tude  effectuee  en  collaboration  avec 
le  Centre  Technique  de  Communication  et 
d'lnt^gration  d'Ateilers  et  concernant  le 
diagnostic  de  pannes  d'une  machine-outli 
a  commands  num^rique. 

Ces  deux  projets,  alnsi  qu'une  activite  de 
recherche  et  developpement  complemen- 
taire  ont  apporte  au  Ddpartement  Intelli¬ 
gence  Artificielle  une  experience 
correspondant  ii  un  effort  poursulvl 
depuls  sept  ans.  Cet  effort  se  fraduit 
aujourd'hui  par  la  disponibllite  d'un 
"Environnement  Logiciel  pour  la  Mainte¬ 
nance  Corrective"  (ELMC)  a  I'dtat  de 
maquette. 

L'objectif  de  I'outil  ELMC  est  le  sui- 
vant  : 

A  un  dquipement  industriel  donne, 
(un  avion,  un  syst6me,  un  equipement,...) 
on  veut  pouvoir  assocler  un  logiciel  d'ai- 
de  d  la  maintenance  corrective  spdcifique. 
Les  capacites  de  ce  logiciel  dolvent  etre 
adaptables  selon  le  contexts,  et  sa  reali¬ 
sation  doit  etre  effectude  e  un  coiit  mini¬ 
mum, 

Une  originalite  de  I'outil  ELMC 
consists  e  gdndrer  automatiquement  le 
logiciel  d'aide  i  la  maintenance  e  partir 
d'un  environnement  de  developpement. 
(FiG.  5).  Chaque  type  d'utilisateur  peut 
alnsi  utiliser  les  formalismes  et  connais- 
sances  qui  leur  sont  ndcessalres. 

Une  seconds  originalite  tient  a 
I'adaptivite  de  I'appllcatlon  aux  ressour- 
ces  disponibles  :  la  souplesse  de  I'appli- 
catlon  peut  etre  moduiee  en  fonction  de 
la  puissance  de  calcul  disponible  et  des 
temps  de  rdponse  ndcessaires. 

Ces  deux  avantages  sont  obtenus  en 
faisant  cooperer  les  techniques  classiques 
de  diagnostic  de  pannes  (maintenance 
integree  par  example)  et  les  techniques 
de  rintetllgence  artificlelle.  Oiffdrents 
niveaux  de  connalssance  sont  utilises  :  en 
particuller,  I'emplol  de  I'envlronnement 
de  ddveloppement  consists  d  rAallser  une 
description  hidrarchlsde  de  I'^qulpement 
selon  des  points  de  vue  fonctlonnel. 
structural  et  comportemental. 

Le  ddveloppement  d'un  prototype  plus 
ergonomique  de  I'outil  ELMC  est  en  cours 
dans  I'envlronnement  SMECI  de  la  Socldtd 


ILOG.  L'expdrience  accumulee  permet  main- 
tenant  de  repondre  rapidement  ii  tout  besoin 
dans  le  domaine  du  diagnostic  de  pannes  : 
en  particuller,  I'appllcatlon  du  savoir-faire 
acquis  a  la  maintenance  hors  ligne  des  dqui- 
pements  de  I'avlon  RAFALE  est  en  cours,  par 
le  biais  de  I'etude  d'un  outil  d'aide  a  la  Spe¬ 
cification  des  Procedures  de  test. 


10.  CONCLUSION  : 

La  maintenance  integree  telle  qu'elle  a 
ete  developpee  sur  nos  avions  d'armes  et 
leurs  dquipements,  permet  d'obtenir  des  per¬ 
formances  tres  interessantes  sur  le  plan  du 
diagnostic  des  pannes.  La  politique  globale 
retenue,  consistant  e  faire  profiler  les  eche¬ 
lons  de  maintenance  aval  des  resultats  obte¬ 
nus  par  les  echelons  amont  sous  forme 
informatique  (par  I'intermedialre  de  medias 
appropries)  permet  d'envisager  I'utilisation 
de  rintelligence  Artificielle  de  manlere  ration- 
nelle. 

La  mise  en  oeuvre  conjointe  de  la  main¬ 
tenance  integree  basee  sur  le  test  d'integrite 
et  de  rintelligence  artificielle  permet  le  deve¬ 
loppement  de  systemes  expert  de  diagnostic 
de  panne  a  cout  faible  : 

•  En  temps  reel  sur  avion  (^i  terme  rela- 
tivement  iointaln) 

•  En  maintenance  complementaire  au  sol  (a 
moyen  terme) 

•  Aux  ateliers  de  maintenance  hors  ligne  et 
industrielle  (en  cours  de  realisation) 

Les  avantages  attendus  de  cette  configu¬ 
ration  sont  : 

•  Augmentation  de  la  finesse  de  diagnostic 
automatique  en  temps  r^el  (localisation 
d'URA  en  panne) 

•  Reduction  des  temps  de  diagnostic  el  de 
validation  de  chaines  fonctionnelles  en 
maintenance  complementaire  au  sol.  tout 
en  redulsant  le  nombre  et  la  qualification 
des  mecaniclens  necessaires; 

•  reduction  du  temps  moyen  de  depannage 
d'une  URL  en  atelier  (de  I'ordre  de  45 
minutes  e  1  heure). 
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Discussion 


I.  J.  Bart,  United  States 

Did  the  1983  study  on  the  MIRAGE  develop  data  on  the 
reduction  of  retest  events  using  AI  techniques? 
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Due  to  the  good  performance  of  our  system  having  less  than 
15%  of  false  removal  rate,  the  focus  of  this  study  was  to 
evaluate  the  software  volume  and  processing  power 
required  to  embed  in  avionics  equipment,  a  knowledge 
based  real  time  diagnostic  system  and  to  determine  the 
proper  technical  approach. 
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^  Themaintenanceeflbrtintennsoftiineandcostofinodem 
avionic  systems  is  driven  by  the  increasing  complexity.  To 
achieve  the  required  operational  availability  of  aircraft,  the 
maintenance  turn-around-times  and  logistic  support  needs 
to  be  optimized.  Expert  Systems  seem  to  be  a  promising 
tqqjroach  to  increase  the  effectiveness  of  on-board  and 
ground-based  test  and  diagnosis  systems.  A  knowledge 
based  approach,  using  inference  techniques,  that  can  also 
handle  uncertain  and  incomplete  information,  was  used  to 
support  detection  and  isolation  of  problems  in  avionic 
equipments.  A  technology  demonstrator,  suppmtitig  the 
TORNADO  check-out  system,  has  been  developed  and 
tested.  The  expert  system,  called  TORRES  (TORNADO 
Radar  Readiness  Expert  System),  supports  d^^g  staff 
with  various  levels  of  expoience.  The  scope  of  the  error 
detection  encompasses  the  TORNADO  Terrain  Following 
and  Ground  Mapping  Radarsystem,  down  to  module  levd. 
The  main  task  of  TORRES  is  the  identifkatian  and 
isolation  of  errors  that  occuned  during  the  previous  flight 
The  expert  system  is  also  able  to  exclude  errors,  that  were 
generated  by  other  systems  capable  of  changing  the  state 
of  the  radar  system  and  isolate  the  cause.  Other  influences 
like  EMC,  exceeding  avionic  systems  acceleration  limits 
and  weakher  effects  ate  taken  under  consideration  and 
reported^ICstaior  is  left  without  an  associated  case, 
spixial  testnms'hra^wggested.  An  explanation  facility 
generates  detailed  dAmfing,i»orts. 

MJWTROPUCTIQN 

The  maaitenance  and  siqiport  of  technically  cmpiex 
systems  develops  into  an  increasiiigly  difflcult  task.  This 
problem  is  compounded  by  the  shorttge  of  qualified  and 
wen  irtined  specialists.  As  a  result,  a  lot  of  support  and 
mainte  ance  work  has  to  be  performed  by  rather  quickly 
trainer  staff. 

The  proliferatian  of  more  comfortaMe  to  use  expert  sys¬ 
tems  appmn  as  a  partial  remedy  to  the  problem.  An  expert 
system  has  the  accnmulaied  knowlet^  and  experience 
readily  available  and  with  an  im^pated  explanatioo 
facility  win  support  the  imderstanding  and  the  compre¬ 
hension  of  the  produced  lesidts.  This  type  of  system  has 
been  sufficiently  successful  and  appears  to  gm  stqjport  by 


its  users. 

The  design  of  a  KBS  generally  dqrends  on  the  assumption 
of  cooperative  information  sources,  be  it  electronic  or 
human.  However,  field  tests  have  shown,  that  there  are 
instances  of  antagonistic  knowledge  sources.  As  an 
example  may  serve  TORRF.S,  the  TOtnado  Radar 
Readiness  Expert  System.  TORRES  is  a  diagnose  and 
verification  system  to  support  fault  detection  for  the 
TORNADO  nose  radar  system.Itis  an  interesting  example, 
because  the  complexity  of  the  system  is  very  high  and  it  is 
highly  interconnected  with  various  other  subsystems. 

3.0  ONBOARD  CHECK-OUT  SYSTEM 

The  TORNADO  flghter  aircraft  is  equipped  with  an 
onboard  check-out  system.  During  startup  of  the  avionics 
suite  of  the  aircraft  and  during  flight,  the  TORNADO 
maiiKomputer  software  conducts  a  series  of  tests  with  the 
Built  In  Test  Equipment  (BITE)  of  the  different  subsys¬ 
tems.  The  BITE  of  the  individual  subsystems  isolates 
possible  faults  and  after  some  processing  with  combina¬ 
torial  logic  displays  its  result  as  a  flashing  diode  on  the 
Central  Maintenance  Panel  (CMIO  to  indicate  a  faul^  Line 
Replacable  Unit  (LRU).  A  warning  is  furthermore  dis- 
idayed  on  a  Central  Warning  System  (CWS)  in  the  cockpit 
toaleitthecrewof  apossible  injunction.  Hgure  1  ’Signal 
Representation’  shows  part  of  the  signal  flow  of  the 
onboard  check-out  system.  The  maincomputer  software 
has  limited  capabilities  to  clearly  identify  die  detected  and 
recorded  problems  by  the  BITE.  It  furthermore  has  no 
means  to  track  down  problems  not  detected  by  the  BITE, 
but  merely  examines  the  physical  connection  boween  the 
nuuncomputmr  and  the  avionic  system. 

Unfortunately,  mishandling  of  the  avionics  equipment  can 
cause  the  generation  of  a  transient  fault,  which  appears  as 
a  latched  fault  in  the  CMP.  To  compound  the  problem, 
operalon  of  the  aircraft  are  sometunes  rductait  to  admit 
or  iBiawaie  of  those  mishandling  errors.  The  conflict 
arising  is,  does  an  LRU  need  replacement  beoHise  of  the 
CMP  fault  indicatioo,  even  if  subsequent  checks  indicaie 
no  fault,  or  not 
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GMR-Amber  Doppler-Unlock  R-ALT-Fail  SAHR-Status  UHF-VHF-Transmit 

TFR-Red  —  IN-Status  Weather-Effects 


Figure  1 :  Signal  Representation 


Depending  on  the  technical  experience  of  the  maintenance 
personnel,  a  frequently  applied  method  of  fault  elimination 
was  the  complete  exchange  of  the  subjected  Line 
Replaceable  Unit  (LRU).  This  tedious  fault  diagnosis 
n^atively  influences  the  following  issues. 

*  tum-around  times 

*  availability  of  the  weapons  system 

*  logistics  and  material  flow 

Because  of  the  demanding  functional  requirements, 
modem  avkxiic  systems  are  composed  of  several  complex 
and  highly  integnded  systems  and  subsystems  which  have 
to  be  easily  maintainable.  These  requirements  with  respect 
to  maintenance  demand  the  utilization  of  modem  infor¬ 
mation  processing  methods.  The  software  has  to  utilize  all 
the  available  knowledge  sources  (analytical,  empirical 
knowledge)andhas  toexhibitaflexibility  thatexten^past 
the  boundaries  of  purely  sequential  program  execution. 
These  requirements  favour  utilisation  of  rule-based 
systems  for  ground-based  diagnose  systems  for  mainten¬ 
ance. 

4j1i  expected  advantages 

Due  to  the  nature  of  the  ta^  of  fault  detection  and 
verification,  the  solutian  finding  process  heavily  dqrends 
on  the  recorded  data  and  has  the^ore  to  be  flexible  and 
opportuniatic.  The  ability  to  focus  on  certain  problem  areas 
doing  the  development  of  the  KBS  was  utilized  to  focus 
on  difficult  to  iscAue  faults.  The  explanation  facility  of  the 


KBS  [Hovides  furthermme  clues  for  the  human  user  to 
better  understand  results  produced  by  the  KBS,  thereby 
increasing  efficiency.  Sorne  of  the  advantages  are: 

*  improved  fault  diagnosis 

The  accumulation  of  several  areas  of  knowledge 
and  experience  provides  a  knowledge  base  much 
more  powerful  than  the  sum  of  its  individual 
parts.  This  enables  the  maintenance  personnel  to 
better  detect  and  isolate  faults  and  furthermoe 
increase  the  individuals  knowledge  through  the 
explanation  facility. 

*  accelerated  maintenance 

Maintenance  times  are  reduced  since  fault 
detection  is  more  accurate,  iher^y  reducing 
time-  and  material  intensive  disassembly  and 
assembly  of  the  subsystems. 

*  shorter  tum-around  times 

Due  to  the  accelerated  maintenance,  the  turn¬ 
around  time  of  the  individual  aircraft  is  also 
reduced,  increasiitg  the  availability  of  the  aircraft. 

*  reduction  of  cost  of  ownership 

Better  fault  isolation  and  faster  maintenance 
decrease  the  cost  of  ownership. 

*  know-how  transfer 

The  explanation  facility  of  TORRES  will  sup¬ 
plement  and  enhance  the  know-how  and  eiqteri- 
ence  of  the  maintenance  personnel. 
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*  conservation  of  knowledge 

The  knowledgebase  of  TORRES  offers  con¬ 
tinuous  access  to  knowledge  of  several  areas. 
Newly  acquired  experience  or  knowledge  can  be 
added  to  the  domain  knowledge  to  keep  the  KBS 
always  on  the  highest  level  of  experience. 

SJt  SYSTEM  IMPLEMENTATION 
The  implementation  of  TORRES  had  been  divided  into 
two  phases.  During  the  first  phase  three  demonstrators 
were  devek^ted  running  on  Texas  Instruments  and  Sym¬ 
bolics  LISP  machines.  The  developing  environment  used 
was  the  erqtert  systems  shell  ARToflnference  Corporation 
[1].  These  demonstrators  were  used  as  experimental  plat¬ 
form  to  study  appropriate  techniques  and  methods  for  the 
acquisitkm  and  rqxresentation  of  knowledge  and  to 
develop  a  useful  inference  engine  to  be  used  in  the  KBS. 
The  domain  knowledge  of  the  system  was  drawn  from 
several  areas.  It  includes  information  Grom  system  design, 
from  the  development  and  integration  and  from  experience 
gathered  by  system  use  and  maintenance. 

TORRES  is  designed  to  support  debriefing  staff  at  various 
levels  of  experience.  The  scr^  of  error  detection 
encompasses  the  TORNADO  Terrain  Following  Radar 
(TFR)  and  the  Ground  Mapping  Radar  (GMR)  from  the 
system  level  down  to  the  module  level.  It  was  realized 
however,  that  the  diagnosis  process  could  not  be  restricted 
to  the  two  radar  systems  otdy.  Faults  and  [HoUems 
occurring  in  rdaied  ^sterns  could  easily  propagate 
erroneous  signals  into  the  two  radar  systems  and  create 


malfunctions  there.  This  required  the  inclusion  of  telaled 
system  faults  into  the  knowledge  base.  Aiiditiooal 
influences  like  EMC,  weatho'  effects  and  excesave 
g-forces  had  to  be  tidcen  into  account  also.  Figure  2 
‘TORRES  Rule  Structure’  shows  the  tdation  of  the  dif¬ 
ferent  rule  classes  to  each  other. 

During  the  second  phase,  TORRES  was  inqilemenled 
using  the  expert  system  shell  KEE  (InidliCotp  [2]),  that 
offered  the  advantage  of  porting  the  resulting  software  to 
conventional  hardware  without  restricting  its  overall 
functionalily.For  this  stqtaCompaq 386/20 runningunder 
UNDC  was  used. 

6.0  SYSTEM  PERFORMANCE 

TORRES  is  invoked  during  the  post-flight  inqtection  of 
the  radar  system.  During  the  debriefing  session,  mal- 
futKtions  of  the  radar  system  are  analyzed  widi  the 
objective  to  decide  upon  the  tqgtrt^priate  maintenance 
action  to  be  udcen.  If  the  fault  cannot  be  traced  to  a 
subsystem  within  the  radar  system,  TORRES  will  identify 
the  most  probable  system  to  be  the  genoator  for  the 
jxopagated  fault  This  would  be  a  well  suited  interface  to 
an  overall  avionic  deteiefing  system  consisting  of  several 
individual  KBS  for  the  various  subsystems. 

Hi!  SolutioB  Protess 

At  debriefrng  the  recorded  results  of  the  BITE  along  with 
other  gathered  information  provided  by  the  crew  is  loaded 
into  TORRES  either  as  a  textflle,  interactively  or  manually 


91  1113  022 


91-15527 


22-4 


an  edilor.  A  preproccMor  in  the  KBS  scans  the  file  for 
k^words  to  he^  focus  on  the  relevant  to|Mcs.  Additional 
infosmatiaa.  be  it  related  knowledge  or  experience,  is 
asaociaMi  with  the  k^wQids  to  establish  a  base  for  further 
ptocessii^  One  or  more  hypothesis  ate  selected  with 
reqtea  to  the  accumulated  focts  and  information.  The 
hypothesis  ate  assigned  one  of  four  certainty  classes,  that 
lange  fiom  ’suspected  fault’  to  ’deGnite  fault’.  The 
hypothesis  with  tte  highest  certainty  class  is  selected  and 
a  process  is  started  to  evahiate  the  probability  of  the  fault 
TORRES  provides  a  graphical  user  interface  and  b^ins  a 
questioning  session  to  obtain  additional  information  from 
the  |Mlot  or  the  crew.  The  questions  can  be  answered  with 
either  ’YES’,  ’NO’  or  ’UNKNOWN’.  Yesand  noanswers 
are  directly  used  in  the  solution  process  while  an  unknown 
is  once  counted  as  a  yes  and  as  a  no.  One  answer  will 
coturfouie  in  the  mid  to  a  larger  extent  to  the  result  than 
the  other,  influencing  the  cenainty  class  of  the  hypothesis. 
The  result  is  a  hypothesis  of  a  fault  with  an  associated 
certainty  class.  According  to  this  procedure  the  rest  of  the 
hypothnes  are  processed.  The  output  containing  infor¬ 
mation  about  the  diagnosis  process  and  explanations  is 
displayed  on  the  screen  and  printed  as  a  text  file.  It  can 
consist  of  series  of  actions  to  be  performed  to  eliminate  the 
fault,  e.g.  rqilace  LRU4  or  contnd  the  wiring  between 
LRUlandLRU4. 

d J  Software  Environment 

The  Expat  System  Shell  KEE  provides  the  environment 
in  which  TORRES  will  run.  KEE  howeva,  needs  as 
supp«ting  envirorunent  a  platform  that  hosts  Common 
LISP  (Symbolics  LISP  Madiines,  TI  Explorer,  worksta¬ 
tions  or  PCs).  In  our  example  a  PC  (Compaq  386/20)  was 
used  tunning  unda  UNIX  (386/ix  [3])  with  Lucid  Com¬ 
mon  LISP.  The  Symbolics  LISP  machine  and  the  Tl 
Explorer  provide  a  gtrqihical  interface  tight  on  the  KEE 
levd,  whereas  on  the  PC,  additional  interfacing  to 
MS-Windows  is  necessary,  which  requites  the  emulatitm 
of  MS-DOS  on  an  intermediate  level. 

This  additional  functionality  is  achieved  using  VP/ix  of 
Interactive  Syftems,  an  MS-DOS  emulation  program.  To 
guarantee  the  above  mentioned  functionality,  two  pro¬ 
cesses  are  active  unda  UNIX.  The  processes  shown  in 
Figure  3  ’Software  Environment’  ate: 


Application 


User  Interface 


KEE 


Ludd 
Oommon  LISP 


CO 


MS-DOS 

(Emulation) 


^  UN&CSystem 

'  i-' 


Figures:  Software  Environment 


63  Execution  Sneed 

Tests  with  respect  to  the  execution  speed  have  been 
conducted  on  two  machines.  One  was  a  Symbolics  3650 
nmning  unda  GENERA  [4]  and  the  olha  was  a  PC 
Compaq  386/20  running  unda  UNIX.  The  test  data  sets 
for  b^  machines  were  identical  and  consisted  of  aircraft 
information  provided  by  a  flight  crew  afta  a  hypothetical 
mission. 


SYSTEM 

Compaq  386/20 

Symbolics  3650 

Operating  System 

UNIX-VP/ix 

Genera 

Software  Environment 

Lucid-Uap 

Common  Lisp 

Set-Up  (sec] 

120 

320 

Diagnosis  [sec] 

880 

250 

Table  1:  Peifomnaoice  Results 


*  Lucid  LiSP  with  KEE  and  the  application 
TORRES 

*  VPfix  MS-DOS  emulator  with  MS-Windows  as 
nsaiiuaCace 

Interprocess  communication  between  the  KEE  applicatkm 
TORRES  and  MS-Windows  is  provided  by  UNDC. 


TORRES  was  started  on  both  machines  with  these  fries. 
Since  both  operating  systems  GENERA  and  UNIX  support 
multi-tasking,  the  results  obtained  could  strongly  dqiend 
on  the  actual  workload  of  the  system  at  the  time.  To 
increase  the  transparency  of  the  r^ts,  two  types  of  tests 
were  conducted,  one  for  the  time  required  to  load  the 
application  and  anotha  fa  the  time  retpiired  to  obtain  the 


rfiagnnsis  results.  The  outcome  of  the  tests  are  shown  in 
TaMe  1  ’Perfonnance  Results’  and  Figure  4  ’Peifcmnance 
Comparison*. 


Figure  4;  Performance  Comparison 

The  set-up  time  of  TORRES  on  the  PC  was  shorter  by  the 
factor  of  2.7  :  1  than  on  the  Symbolics.  Responsible  for 
this  difference  is  the  multitasking  feature  of  GENERA  and 
the  overhead  to  invoke  TORRES  within  KEE.  The  ^peed 
perfonnance  is  clearly  different  for  the  diagnosis  task.  Here 
the  Symbolics  is  lea^g  by  the  factor  of  3.S :  1  over  the 
PC.  Responsible  for  the  fast  and  very  steady  performance 
of  the  LISP  machine  is  the  support  provirM  to  USP  by 
the  special  hardware  and  the  sophisticaied  concept  of 
garbage  coUection  (dynamic  and  ephemeral  garbage  col¬ 
lector)  provided  by  GENERA.  The  weaker  performance 
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RgumS;  UNIX  Tuning 

on  the  PC  under  UNIX  can  be  attribaled  to  the  foDowing 
reasons.  The  laak  of  garbage  coUection  was  not  optimized 
and  thetefbie  leas  efficku  than  that  of  GENERA.  Several 
UNIX  system  parameters,  like  kernel  streams,  message 


passing,  paging  and  shared  memory  access  had  to  be  tuned 
to  improve  the  operating  system  efficiency.  The  grigihs  in 
Hgure  S  ’UNIX  Tuning’  show  the  improvememacteved 
by  the  tuning  measures.  They  are  significant  during  the 
fust  test  runs,  deteriotale  howler  during  subseqnem  runs. 
They  are  assumed  to  assymtotically  qiproach  a  steady 
state,  well  above  the  Symbolics  execution  time. 

7.0  CONCLUSIONS 

WiUi  the  application  TORRES  a  rule-based  diagnosis 
system  has  bm  realized  to  provide  on-line  support  for  the 
TORNADO  maintenance  crew.  The  system  runs  on  USP 
machines  (Symbolics,  TI  Explorer)  and  on  conventional 
PC  based  hardware.  The  grafriiical  user  interface  supports 
comfortable  usage.  Through  the  improved  fault  dia^iosis, 
acceleratedmainienance  is  achieved,  reducing  turn-around 
times  thereby  increasing  system  availability. 

REFERENCES 

[1]  ART  Automated  Reasoning  Tool.  V.  3.2  1987,  Infer¬ 
ence  Coiporation. 

[2]  KEE,  Knowledge  Engineering  Environment,  V.  3.1 
Dec.  1987,  IntelliCmp. 

[3]  UNIX  386»fix.  V.  1.06  July  1988  and  Wftx,  V.  1.1.0 
Aug.  1988,  Interactive  Systems  Corporation. 

[4]  Operating  System  Genera,  V.  7.2  Feb.  1988,  Symbolics 
CmpMation. 


Discussion 

I.  E.Labatt,  United  States 

Could  X-windows  and  other  new  software  be  used  instead 
of  MS-windows,  and  a  IX>S  emulator  to  speed  up  the 
processing  time  on  the  Compaq  computer? 

Author. 

I  agree  with  you,  that  the  system  performance  is  influenced 
by  the  overhead  of  using  the  MS  DOS  emulator  as  interface 
to  MS-Windows.  Probably  the  proposed  tools  would 
provide  a  better  performance.  However,  at  the  time  of 
development  they  were  not  available  for  use  on  a  PC. 
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Abstract 


Introduction 


AITEST  is  a  real  life  expert  system  designed  to  serve  as 
a  decision  aid  and  productivity  tool  for  test  engineers  and 
technicians.  Oriented  for  the  functional  level,  AITEST  is 
designed  to  troubleshoot  large  scale  UUT’s  (Unit  Under 
Test)  that  contain  analog,  digital  and  mechanical  modules 
in  electronic,  elcctr^ptic,  hydraulic  or  mechanical  sys¬ 
tems  and  devices,  ai 

This  paper  describes  a  typical  application  of  AITEST  in 
an  intermediate  •  level  maintenance  facility.  The  UUT 
(Unit  Under  Test)  discussed  in  this  application  note  is  a 
Radar  Modulator  (RM)  embedded  in  the  Radar  System  of 
a  military  aircraft 


Following  a  brief  description  of  the  Radar  Modulator 
structure  and  functions  and  its  current  test  tools,  we 
proceed  to  describing  our  experience  in  using  AITEST  to 
troubleshoot  this  device. 


Keywonis 


-  Diagnosis 


-  Expert  Systems 


•  Equipment  Maintenance 


AITEST  is  a  real  life  expert  system  designed  to  serve  as 
a  decision  aid  and  productivity  tool  for  test  engineers  and 
technicians.  Oriented  for  the  functional  level,  AITEST  is 
designed  to  troubleshoot  large  scale  UUT's  (Unit  Under 
Test)  that  contain  analog,  digital  and  mechanical  modules 
in  electronic,  electro-optic,  hydraulic  or  mechanical  sys¬ 
tems  and  devices. 

For  a  given  set  of  test  results,  AITEST’s  diagnostic  algo¬ 
rithm  identifies  candidate  faulty  modules  and  ranks  them 
in  a  descending  order  of  their  likelihood  of  failure.  It  may 
also  /.oom-in  for  further  a.s.sc.ssing  the  fault  likelihood  of 
each  individual  sub-module.  When  the  number  of  pos¬ 
sible  faults  is  relatively  large  so  that  no  final  conclusion 
can  be  immediately  reached,  AITEST  identifies  those 
areas  in  the  UUT  that  are  likely  to  contain  faulty  modules, 
and  suggests  diagnostic  goals  for  the  next  stage.  The  user 
may  accept  these  suggestions,  or  set  his  own  diagnostic 
goals. 

Once  the  goals  have  been  set,  AITEST  identifies  and 
evaluates  the  u»ts  that  may  be  used  for  achieving  them, 
and  proposes  the  most  cost-effective  test  The  sequence 
of  tests  is  by  no  means  predetermined;  rather  it  is  adap¬ 
tively  reordered  based  on  test  responses,  thereby 
eliminating  redundant  tests. 

AITEST  is  capable  of  diagnosing  multiple  faults,  and  al¬ 
lows  an  unlimited  number  of  hierarchical  levels  in  the 
UUT  structure.  It  is  therefore  applicable  to  all  levels  of 
testing;  field  service,  intermediate  labs  and  depot  labs. 


Abo  wkk:  TdL  Avb  Uobtrsky  Foeolty  ofManogement 
Fooim  Avn.  T*l  A  Wv  69978,  Israel 


23-2 


AITEST  also  includes  many  non>AI  (Artificial  Intel¬ 
ligence)  features  that,  together  with  the  diagnostic  en¬ 
gine.  form  a  comprehensive  solution  for  the  practicing 
test  engineers  and  technicians.  These  include: 

OnDoc  (on-line  documentation)  is  AITEST's  tool  for 
producing  and  using  textual  and  pictorial  documentation 
of  the  device  being  tested,  test  instructions,  repair  proce¬ 
dures  and  logistics  information.  Based  on  object-  oriented 
programming  techniques,  OnDoc  offers  the  flexibility  of 
a  hypermedia/  hypertext-like  service  manual. 

AITEST’s  DB-LRN  is  a  database  tool  used  for  storing  and 
retrieving  test  results,  diagnoses  and  repair  actions. 
Beyond  the  internal  database  tools,  AITEST  can  export 
its  database  files  to  commercial  DBMS’s.  AITEST.  of 
course,  utilizes  this  database  to  learn  from  experience, 
continuously  refining  and  improving  its  knowledge. 
AITEST  has  been  designed  with  an  open  architecture  to 
enable  flexible  interfacing  with  test  instrumentation  and 
ATE.  It  can  be  used  either  manually,  embedded  in  an  ATE 
system  or  as  a  controller  of  test  instrumentation. 

AfTEST  has  already  been  applied  to  numerous  real  life 
UUT’s  coming  from  a  wide  variety  of  fields;  military  and 
aerospace  devices,  peripheral  equipment  for  computers 
(monitors,  printers,  disk  drives),  communication  boards 
(PABX,  radio  telephone),  automotive  devices,  and  test 


equipment  This  paper  describes  a  typical  application  of 
AITEST  in  an  intermediate  -  level  maintenance  facility. 

The  UUT  (Unit  Under  Test)  discussed  in  this  application 
note  is  a  Radar  Modulator  (RM)  embedded  in  the  Radar 
System  of  a  military  aircraft  The  RM  unit  is  currently 
tested  using  a  Radar  Test  Bench  System  (RTBS).  RTBS 
is  a  traditional  tester  equipped  with  stimulus  generators 
and  measurement  devices.  A  set  of  tests  has  been  defined 
for  the  unit,  for  which  the  RTBS  produces  PASS/FAIL 
results.  The  primary  diagnostic  tool  is  a  service  manual 
that  includes  50  pages  of  fairly  lengthy  diagnostic  charts. 
Following  a  brief  description  of  the  Radar  Modulator 
structure  and  functions  and  its  current  test  tools,  we 
proceed  to  describing  our  experience  in  using  AITEST  to 
troubleshoot  this  device. 

Radar  Modulator:  Overview  of  Structure 
and  Functions 

The  primary  function  of  the  RM  is  to  produces  modulated 
pulse  output,  which,  after  amplification,  activates  the 
transmitter  tube.  The  unit  is  functionally  divided  into  the 
following  modules  (see  Figure  I); 


Flgun  1:  Radar  Modulator  Functional  Oaserption 


1. 

VI  A  V2 

Chaiga  and  Discharga  tubas,  which  act  as  switching  davicas. 

2. 

A1 

Chaiga  triggar  pulsa  ganarator  module.  Its  main  functionality  is  similar  to  that  of  an  amplifier. 

3. 

A2 

Diaeharga  triggar  pulse  ganarator  module. 

4. 

A3 

Fault  monitoring  module. 

5. 

A4 

SCR  gala  drivar  whose  main  function  is  to  anaUa/inhibit  charga/discharga  triggers  depending 
on  fault  conditions  detection  (a.g.  diarga  puisa  ganarator  ovarcurrant  condition). 

6. 

VR1AVR2 

Voltaga  raguiators  and  switching  assambly  (K1  through  K4). 

Current  practice  in  testing  the  Radar 
Modulator  (without  AiTEST) 

Using  the  service  manual,  a  technician  troubleshoots  the 
RM  in  the  following  way: 

The  technician  runs  a  series  of  about  20  pre-ordered  Ac¬ 
ceptance  Tests  (e.g.  Time  Totalizing  Meter  Test,  Pulse 
Output  Test  etc.).  I f  he  completes  running  the  acceptance 
tests  without  a  single  FAIL  result,  the  testing  procedure 
is  terminated.  In  case  of  a  FAIL  result  in  one  of  the  accep¬ 
tance  tests,  the  technician  is  referred  to  the  diagnostic 
flowchart  for  fault  isolation.  The  flowchart  involves  a 
total  of  about  23  diagnostic  tests  (e.g.  checking  test  point 
number  164  -  charge  pulse  gate  test,  or  D14  -f  25 V  regu¬ 
lated  voltage  test.  etc.). 

In  some  cases,  the  diagnostic  chart  ends  with  a  definite 
i.solation  of  the  fault.  In  many  other  cases,  however,  the 
diagnostic  chart  ends  with  a  group  of  suspected  modules 
and  leaves  final  isolation  to  the  technician.  For  instance, 
one  branch  of  the  flow  chart  ends  with;  “Test  and  Repair 
VI,  V2,  Ul-2...”.  In  any  case,  the  flow  chart  only  refers 
to  top-level  modules,  and  further  isolation  is  always  left 
to  the  next  stage  of  testing  (sub-assembly  testing). 


Limitations  of  Current  Practice 

There  are  several  major  disadvantages  in  using  the  con¬ 
ventional  diagnostic  flowchart  approach; 

a)  The  total  number  of  test  result  combinations  that  need 
to  be  analyzed  by  any  diagnostic  chart  is  in  the  order 
of  2":  where  n  is  the  average  number  of  diagnostic 
tests  per  case  (assuming  that  every  diagnostic  test 
may  have  only  a  PASS  or  FAIL  result). 

For  the  RM  unit,  a  typical  number  of  tests  per  faulty 
unit  is  16,  which  means  that  we  have  to  spwify  the 
diagnostic  interpretation  of  about  6S000  (2  ;  com¬ 
binations  of  test  results.  Since  it  is  inconceivable  to 
cover  all  these  combinations,  the  diagnostic  chart 
docs  not  go  all  the  way  down  and  often  ends  up  with 
a  list  of  suspected  faulty  modules.  In  these  cases,  final 
isolation  depends  on  the  experience  ,  skill  and 
knowledge  of  the  individual  technician  who  is  testing 
the  unit  This  situation  is,  of  course,  undesirable  in 
case  of  a  junior  inexperienced  technician. 

b)  The  test  execution  sequence  dictated  by  the  chart  is 
predetermined,  and  may  not  be  the  most  cost-  elTcc- 
tive.  Short-cuts  through  the  flow  chan  arc  not  al¬ 
lowed.  If  (he  technician  deviates  from  the  chart’s 
guidance,  the  chan  becomes  useless  for  subsequent 
steps. 

c)  The  process  of  searching  forward  and  backward 
through  the  service  manual  is  cumbersome  and  quite 
time  consuming.  Quite  often  the  operator  forgets 
where  he  is  coming  from,  or  what  are  the  test  results 
so  far.  In  fact,  too  often  he  ignores  the  service  manual 
altogether. 


d)  Service  manuals  do  not  preserve  and  make  use  of  the 
experience  (expertise)  gained  by  the  electronic  en¬ 
gineers/technicians.  When  an  experienced  technician 
leaves,  his  knowledge  is  lost,  and  the  less  ex¬ 
perienced  operator  starts  from  scratch. 

e)  The  time  and  cost  of  building  a  comprehensive  ser¬ 
vice  manual  based  on  fault-isolation  flow  charts  is 
very  substantial.  If  the  UUT  goes  through  revisions 
(implying  revisions  in  the  test  plan),  the  revision  of 
its  diagnostic  chart  is  very  dilTicult,  and  no  inherent 
mechanisms  are  available  to  maintain  consistency. 

The  following  sections  present  the  AITEST  approach  to 
fault  isolation.  The  AITEST  system  consists  of  two  main 
parts.  The  first  part,  the  KB  (Knowledge  Base)  program, 
is  used  to  construct  and  maintain  the  knowledge  base  of 
the  UUT  (Unit  Under  Test).  The  second  part,  the  RT  (Run 
Time)  program,  drives  the  .system  during  the  testing 
process.  Its  core  is  the  diagnostic  executive,  which 
operates  on  the  knowledge  base  to  guide  the  technician 
in  troubleshooting  the  unit. 


Preparation  Stage:  Creating  the  RM 
Knowledge  Base  (KB) 

Using  the  KB  program  of  Aitest,  the  construction  of  the 
UUT  -  specific  knowledge  base  for  the  Radar  Modulator 
took  about  100  hours.  This  included; 

a)  Creating  the  Radar  Modulator’s  block  diagram.  Fol¬ 
lowing  an  analysis  of  the  UUT  structure  from  the  test 
point  of  view,  we  identified  25  lop  level  modules,  18 
of  which  are  further  subdivided  into  sub-modules. 
The  total  number  of  lower  level  SRRU’s  (Smallest 
Repair-Replaceable  Units)  is  95.  Figure  2  shows  the 
top  level  block  diagram,  while  figure  3  shows  the  in¬ 
ternal  structure  of  one  top  level  module. 

For  each  module  in  the  block  diagram  we  also  pro¬ 
vide  additional  data,  such  as  name,  failure  rate  and 
type. 

b)  Describing  43  different  tests,  of  which  about  20  arc 
grouped  together  in  a  section  called  ACCEPTANCE 
tests,  and  the  rest  arc  DIAGNOSTIC  tests.  These  tests 
are  the  same  tests  used  by  the  flow  chart.  Test  descrip- 
lion  includes  the  lest  path  and  several  other 
parameters  such  as  stimulus  and  measurement  types 
and  the  time  it  takes  to  perform  the  test. 

The  path  of  a  test  includes  all  modules  whose  mal¬ 
function  may  cause  the  test  to  FAIL.  This  information 
is  crucial  for  obtaining  correct  diagnostic  assess¬ 
ments.  Therefore,  the  task  of  drawing  the  tesa  paths 
should  be  put  in  the  hands  of  a  person  who  under- 
.stands  well  the  UUT  and  its  tests.  This  person  does 
not  necessarily  have  to  be  the  UUT  designer  (even 
though  this  is  recommended).  In  fact,  in  the  case  of 
the  Radar  Modulator,  the  UUT-spccific  knowledge 
base  was  created  by  the  engineers/technicians  who 
maintain  the  system.  (Over  10  years  passed  since  it 
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Figure  4:  A  typical  example  of  a  lest  path  (test  TP16SPR)  (clashed  lines) 


was  delivered).  The  service  manual  and  other 
documentation  provided  with  the  unit  were  very  in¬ 
strumental. 

A  typical  example  of  a  test  path  is  shown  in  Figure  4. 
Figure  S  shows  the  parameters  required  to  fully 
specify  the  test.  In  this  Figure,  the  Field  “Test  Pro¬ 
gram”  contains  the  name  of  the  test  program  that  an 
ATE  should  run  in  order  to  execute  this  test.  In  the 
case  of  manual  testing,  this  Field  may  be  left  empty 
or  it  may  include  the  name  of  a  short  program  or  text 
file  that  provides  instructions  to  the  technician. 

The  field  “Description”  provides  the  option  to  include 
documentation  related  to  the  test  -  e.g.  a  pictorial  descrip¬ 
tion  of  the  location  of  stimulus  and  response  points. 

It  should  be  emphasized  that  the  diagnostic  flow-chart  of 
the  RM  is  NOT  programmed  into  AITEST.  The  basic  con¬ 
cept  behind  AITEST’s  design  is: 


Tell  AITEST  (once  only)  about: 

□  the  HUT  structure,  in  terms  of  a  functional  block 
diagram,  and 

□  the  TESTS  that  may  potentially  be  used  (i/o  points, 
lest  path,  stimulus  and  measurement) 

and  AITEST  will: 

□  automatically  generate  the  diagnostic  interpretation 
of  any  combination  of  test  results,  and 

□  effectively  manage  the  order  of  test  execution. 

Once  the  description  of  the  block  diagram  and  the  tests  is 
completed,  AITEST  will  comment  on  any  inconsistencies 
or  missing  parts.  After  their  correction,  the  KC 
(Knowledge  Compilation)  program  is  run.  As  a  result,  a 
set  of  files  -  RM-KB  files  -  is  generated,  and  this  com¬ 
pletes  the  preparation  step.  These  files  may  be  copied  to 
diskettes  and  distributed  to  all  of  the  service  laboratories 
where  the  Radar  Modulator  is  maintained.  In  the  service 
laboratories,  only  the  RT  program  of  AITEST  -  described 
in  the  subsequent  sections  -  is  required. 


Run  Time  (RT)  Operation 

The  following  sections  describe  the  use  of  AITEST  to 
troubleshoot  the  RM  unit,  using  the  RT  program. 

Test  case  •  example  1 

Let  us  assume  that  a  fault  exists  in  charge  trigger  gener- 
ator-Al,  which  causes  the  absence  of  the  charge  pulse 
generator  output.  AITEST  first  recommends  to  perform 
acceptance  tests  until  reaching  a  FAIL  result.  AITEST 
then  deviates  from  the  preordered  sequencing  and  auto¬ 
matically  identifies  the  next  best  test  to  perform  at  each 
stage. 

The  first  3  test  results  (consistent  with  A I  being  i3>i!;y), 
are: 

1 .  Time  TOT  (Time  Totalizing  Meter)  =  PASS 

2.  Time  DLY  (10  minutes  Time  Delay)  =  PASS 

3.  TP70-PR(is  MOD  Pulse  Out  Present?)  =  FAIL 

At  this  stage,  AITEST  identifies  a  set  of  modules  that  are 
most  worth  pursuing  at  the  next  stage  and  sets  them  as  the 
goals.  AIT^T  continues  by  automatically  selecting  the 
next  sequence  of  tests  to  be  performed.  Each  test  is 
selected  depending  on  previous  test  results,  and 
AITEST’s  estimation  of  the  test's  information  contribu¬ 
tion  to  further  isolate  the  fault  among  the  suspected 
modules.  Here  is  what  happens  in  our  session: 

1 .  TP163>PR  (is  TP163  output  pulse  present?)  s  PASS 
(This  is  the  right  response  consistent  with  At  being 
faulty). 

2.  TP163-CO  (is  TP163  Wave  Form  Correct?)*  PASS 


3.  TP165-PR  (is  TP165  Output  Pulse  Present?)  =  PASS 

4.  TP165-CO  (is  TP165  Wave  Form  Correct?)  =  PASS 

5.  TP164-PR  (is  TP164  Output  Pulse  Present?)  =  FAIL 

6.  TP64  (is  TP64  -  Trig  Inhibit  -  Present?  if  no  =  PASS) 
=  PASS 

At  this  stage  AITEST  displays  the  following  message  at 
the  top  left  pan  of  the  display:  ‘THERE  ARE  NO  ADDI¬ 
TIONAL  TESTS  THAT  CAN  IMPROVE  THE  DIAG¬ 
NOSIS”.  The  central  part  of  the  screen  shows  the  RM’s 
block  diagram  in  various  colors  where  AITEST’s  diag¬ 
nostic  assessment  is  expressed  by  a  color-coded  repre¬ 
sentation  (c.g.  red  for  FAULTY,  yellow  for  SUSPECTED 
etc.).  This  color  actually  encodes  a  numeric  value  indicat¬ 
ing  a  fault  probability  interval.  This  probability  interval 
is  displayed  by  AITEST  upon  request.  In  our  case  the  top 
ranked  module  is  A1  whose  color  is  reddish,  indicating 
VERY  SUSPECTED  level  (sec  Figure  6). 


Notes 

1.  It  took  only  9  tests  (out  of  about  50)  to  isolate  the 
faulty  module.  AITEST  automatically  skips  perform¬ 
ing  tests  which  are  considered  irrelevant  A  test  is 
considered  irrelevant  if  it  docs  not  conuibute  addi¬ 
tional  information  with  regard  to  suspected  modules 
which  have  to  be  further  isolated 

2.  The  operator,  even  an  unskilled  one,  may  easily  fol¬ 
low  the  test  sequence  suggested  by  AITEST  to  isolate 
the  fault  and  replace  module  A1  at  this  stage. 


Figure  6:AITESTs  diagnosis,  a  fault  in  VR1 


Test  case  >  Example  number  2 

Assume  that  a  fault  exists  in  VRl  (■f2SV  regulator). 

Again,  AITEST  recommends  to  perform  a  sequence  of 
acceptance  tests  until  reaching  a  FAIL  result. 

The  first  3  test  results  (consistent  with  VRl  being  faulty), 
are; 

TIME  TOT  =  PASS 
TIME  DLY  =  PASS 

TP70  PR  =  FAIL  (MOD  PLS  OUT  is  absent) 

Following  this  FAIL  result,  AITEST  dynamically  selects 
the  next  tests,  based  on  their  estimated  information  con¬ 
tribution; 

TP163  PR  =  FAIL 
BITE  5  =  PASS 
BITE  6=  PASS 
BITE  7  =  PASS 
BITE  8  =  PASS 

BITE  S-8  are  a  series  of  tests  designed  to  check  the  fault 
monitor’s  (A3)  -  operation.  Since  A3  is  not  directly  in¬ 
fluenced  by  the  ■«-2SV  regulator,  a  “PASS”  test  result  is 
indeed  what  was  expected. 


INVl  =FAIL 
TP165  =  FAIL 
TP161  *  FAIL 
TP158  =  FAIL 
D14  =  FAIL 

At  this  stage  AITEST  stops  and  ranks  VRl  (+25V 
regulator)  at  the  top  with  a  red  color  indicating  a  FAULTY 
state. 


Notes: 

1.  Since  VRl  is  connected  to  the  input  voltage  line, 
which  affects  many  other  modules,  it  took  13  (out  of 
SO)  tests  to  isolate  the  faulty  module  (VRl). 

2.  At  the  request  to  explain  its  line  of  reasoning  for  each 
module  (or  sub- module),  AITEST  displays  the  list  of 
tests  that  contributed  to  the  diagnosis  directly  or  in¬ 
directly.  This  explanation  may  be  further  clarified  by 
requesting  the  path  of  a  test  from  the  list  to  be  dis¬ 
played. 
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AITEST’s  Ability  to  Learn  from  Past 
Experience  (Data  Base  and  Learning 
Program) 

As  mcniioncd  earlier  in  this  article,  service  manuals  do 
not  preserve  or  make  use  of  the  expertise  gained  by  the 
electronic  engineers  and  technicians.  ATTEST  uses  statis¬ 
tical  learning  algorithms  to  improve  its  initial  diagnostic 
ability.  The  improvement  in  diagnostic  performance  is 
proprotional  both  to  the  number  and  variety  of  different 
test  scenes  saved  in  the  statistical  data  base. 

In  this  case  study,  (the  RM  UUT)  about  50  test  cases  have 
been  saved  in  order  to  refine  AITEST’s  initial  diagnostic 
estimates.  This  refinements  brought  AITEST’s  diagnostic 
performance  to  a  stable  high  performance  start  point  on 
the  learning  curve  before  putting  it  to  actual  use. 
Obviously,  the  data  base  is  useful  in  laboratory  manage¬ 
ment  as  well  as  in  learning.  The  lab  manager  can  use 
AITEST’s  data  base  to  generate  statistics  and  reports,  and 
can  also  port  it  to  the  general  logistic  data  base. 


Conclusions 

The  basic  disadvantages  of  the  conventional  testing  ap¬ 
proach  (using  diagnostic  flow-charts)  are: 

a)  Exponential  (2")  number  of  test  result  combinations 
to  cover. 

b)  Predetermined  sequence  of  test  execution 

c)  Time  consuming  process  of  searching  forward  and 
backward  through  lengthy  manuals. 

d)  Service  manuals  do  not  preserve  experiential 
knowledge. 

c)  Time  and  cost  of  building  comprehensive  flow¬ 
charts. 

AITEST  solves  the.se  basic  problems; 

a)  It  automatically  generates  the  diagnostic  interpreta¬ 
tion  of  any  combination  of  test  results. 

b)  It  automatically  and  effectively  manages  the  order  of 
test  execution. 

c)  It  provides  on-line  documentaion  of  the  UUT  includ¬ 
ing  schematics,  test  instructions,  rcpair/rcplacc  pro¬ 
cedures,  etc.  Together  with  OnDoc,  AITEST 
constitutes  an  electronic  service  manual  of  the  UUT. 

d)  It  preserves  and  makes  use  of  experiential  know  ledge 
(Data  Base  and  Learning  program). 

e)  It  eliminates  the  cost  of  building  fault  isolation  flow¬ 
charts.  . 
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1.  SUJIMARY 

As  a  result  of  the  demands  upon 
maintenance  organisations  to  increase 
availability  of  aircraft  and  the 
increasing  complexity  of  aircraft 
systems,  a  need  for  tools  and 
facilities  to  enhance  the  effectivity 
and  efficiency  of  maintenance  emerges. 
The  National  Aerospace  Laboratory  NLR 
performs  applied  research  with  concern 
to  the  use  of  knowledge  based  systems 
for  condition  monitoring  and  diagnosis 
in  complex  technical  systems.  This 
paper  describes  a  feasibility  study 
(KADAM)  on  the  application  of 
knowledge  based  systems  for  diagnosis 
of  complaints  in  aircraft  systems.  The 
specific  application  selected  for  the 
KADAM  project  (Knowledge-based 
Assistant  for  Diagnosis  in  Aircraft 
Maintenance)  is  a  knowledge  based 
system  to  be  used  by  ground  engineers 
for  troubleshooting  of  an  aircraft 
airconditioning  system. 

This  paper  will  address  the  approach 
taken  in  the  project  and  review  the 
results,  including  the  design  of  the 
proof -of -concept  system.  Particular 
attention  will  be  paid  to  the 
identification  and  formalisation  of 
methods  for  diagnosis.  ^ 


2.  INTRODUCTION 


assistant  could  provide  easy  and  rapid 
access  to  the  information  which  is 
normally  acquired  from  bulky  manuals. 
Also,  knowledge  and  experience  from 
experts  could  be  made  available  to  the 
less  experienced  ground  engineer. 
Maintenance  data  bases  could  be 
coupled  to  the  KBS  in  order  to  provide 
component  reliability  information  and 
the  maintenance  history  of  a 
complaint . 

These  KBS  facilities  should  decrease 
the  time  spent  on  aircraft  systems 
maintenance  and  the  number  of 
incorrect  component  removals  (RTOK) . 
There  might  also  be  effects  towards 
decreased  knowledge  and  experience 
requirements  for  ground  engineers . 

Although  a  KBS  solution  is  not  a 
condition  to  the  objectives  mentioned, 
a  KBS  approach  does  have  the  advantage 
of  enabling  a  relatively  clear 
separation  between  knowledge  on 
(generally  applicable)  diagnosis 
methods  and  knowledge  on  system 
structure  and  -functionality.  Also  the 
explanation  feature  of  a  KBS 
facilitates  learning  and  lessons 
learned  from  operational  use  of  the 
system  can  be  relatively  easy 
implemented. 


Maximum  deployability  of  aircraft  is 
of  prime  importance  to  military  opera¬ 
tors.  This  iii^ses  high  demands  upon 
the  maintenance  organisation  to  ascer¬ 
tain  maximum  availability  of  the 
fleet.  At  the  same  time,  maintenance 
costs  are  to  be  kept  at  a  minimum. 
Hence,  a  need  for  maintenance 
efficiency  with  respect  to  time  as 
well  as  for  effectiveness  continuously 
exists.  This  problem  is  compounded  by 
the  ever  increasing  complexity  of 
aircraft  systems  requiring  more 
knowledge  and  experience  from  the 
maintenance  crew. 

A  solution  to  the  problems  outlined 
above  could  be  the  availability  of  a 
knowledge-based  system  (KBS)  to  assist 
the  maintenance  crew  in  the  process  of 
diagnosing  failures  in  complex 
systems.  A  knowledge-based  diagnosis 


As  a  result  of  the  above,  world-wide 
development  activities  have  started  on 
luiowledge-based  systems  for  diagnosis 
in  aircraft  systems  as  well  as  entire 
aircraft.  Fault  diagnosis  systems  are 
being  developed  as  on-board  aircraft 
systems  and  as  ground-based  systems. 

Under  contract  with  the  Netherlands 
Agency  for  Aerospace  Programs  (NIVR) , 
the  National  Aerospace  Laboratory 
(NLR)  has  investigated  the  feasibility 
of  knowledge-based  systems  to  assist 
ground  crews  in  corrective  maintenance 
of  complex  aircraft  systems.  For  this 
feasibility  study,  the  Fokker  100  air- 
conditioning  system  was  chosen  as  a 
representative  example  of  a  complex 
aircraft  system.  One  of  the  results  of 
the  KADAM-project  (Knowledge-based 
Assistant  for  Diagnosis  in  Aircraft 
Maintenance)  is  a  proof -of -concept 
knowledge-based  system. 


This  paper  has  been  presented  at  the  AGARD  Avionics  Panel  Symposium  on  Machine  Intelligence  for 
Aerospace  Electronic  systems,  Lisbon,  May  16,  1991. 
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3.  PROBLEM  DEFINITION 

Maintenance  may  in  general  terms  be 
defined  as  the  activities  required  to 
bring  an  item  into  a  functional 
condition  or  to  keep  an  item  in  a 
functional  condition.  Hence, 
maitenance  can  be  divided  into 
corrective  activities  and  preventive 
activities  respectively.  Corrective 
maintenance  due  to  problems  which 
occured  during  operational  use  of  an 
aircraft  is  commonly  refered  to  as 
•troubleshooting* . 

If  a  malfunction  occurs  during 


aircraft  operation,  the  crew  fills  out 
a  con^jlaint  form  ("slip*)  which 
describes  the  malfunction,  flight 
conditions  related  to  the  occurence, 
possible  action  taken  by  the  crew  (in¬ 
flight  trouble  shooting  or  fault 
containment)  and  any  other  information 
of  relevance  to  the  con^laint. 

The  slip  (Fig.  1)  is  the  main  source 
of  complaint  information  used  by  the 
ground  engineer  for  diagnosis  of  the 
problem  during  corrective  maintenance 
on  the  ground. 


FLIGHT  NO. 

OEP  STA 

A/C  REG  loOHSTY 

SEO  NO 

ATA  SYSTEM 

POS 

KSSU  COMP  I DENT  NO 

SERIAL  No  InIsERIAL  No  OUT 

OEL 

416 

BFS 

CHB  100186 

N046 

SUBJECT  :  PrtsHurization 

COMPLAINT  :  upon  lift  off  and  touchdown 
thara  is  a  praaaura  surga  for  a  faw 
saconda  of  approx.  2000' /«in 

ACTION  :  Replacad  cabin  prasa  controUar 
Out:  1026U-6  «  115-359 

In  :  1026U-6  «  96-883 

ACTtCM  STATION 

00  MM 

GMT 

AMS 

1101 

0300 

RELEASE  STATION 

00  MM 

GMT 

Figure  1  Example  complaint  form  (slip) . 


Diagnosis  takes  approximately  one 
third  of  the  total  time  used  for 
corrective  maintenance. 

It  is  a  task  which  in  general  requires 
a  considerable  amount  of  knowledge  and 
experience  of  the  ground  engineer. 
Errors  in  diagnosis  result  in  high 
costs,  not  only  because  the  problem 
will  not  be  solved,  additional 
maintenance  is  required  and  aircraft 
availablity  is  reduced,  but  also 
because  fully  servicable  system 
components  may  be  replaced,  resulting 
in  unnecessary  component  maintenance 
activities  (RTOK:  Re-Test  O.K.)  and 
large  and  expensive  stocks  of  spare 
parts . 

The  proof -of -concept  knowledge  based 
system  developed  under  the  KADAM 
project  provides  support  to  diagnosis 
activities.  It  helps  the  engineer  to 
establish  the  exact  complaint,  to 
identify  and  evaluate  the  syn^toms  and 
to  determine  which  maintenance  action 
is  required  to  resolve  the  problem. 

In  order  to  limit  the  scope  of  the 
project,  one  aircraft  system  was 
selected  as  the  application  area,  viz. 
the  airconditioning  system  of  the 
Fokker  100  aircraft.  This  system  was 
selected  because  it  has  well  defined 
interfaces  with  other  aircraft  systems 


and  it  contains  mechanical-, 
pneumatic-  and  electronic  components. 
The  Fokker  100  airconditioning  system 
(airco)  is  considered  representative 
for  modern,  non-avionics  aircraft 
systems . 

The  main  differences  between  the  KADAM 
application  and  other  AI  avionics 
testers  are  that  there  is  no  single 
system  testunit  available,  system 
components  are  distributed  over  the 
entire  aircraft,  components  are  often 
not  directly  accessible  and  the  fact 
that  the  maintenance  engineer  usually 
has  to  work  from  functional 
descrepencies  (complaint  descriptions) 
instead  of  BIT/BITE  results  (Built-In- 
Test  data) . 


4.  KNOWLEDGE  ACQUISITION 

The  two  main  areas  of  knowledge 
applied  during  troubleshooting  of 
aircraft  systems  are  knowledge  of  the 
structure  and  functionality  of  the 
system  which  in  general  are  documented 
during  system  design,  for  ex4ui^le  in  a 
Fault  Isolation  Manual,  and 
troubleshooting  experience  of  ground 
engineers .  Knowledge  from  experience 
is  usually  transferred  to  less 
experienced  personnel  through  personal 
communication  and  does  in  general  not 
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result  in  effective  feedback  to  the 
manufacturer  of  the  aircraft. 

Because  these  two  knowledge  areas  are 
partially  overlapping  and  may  show 
discrepancies,  both  areas  were 
surveyed  extensively.  Maintenance 
documentation  and  design  data  has  been 
provided  by  Fokker  Aircraft  B.V.,  the 
manufacturer  of  the  Fokker  100. 
Information  on  maintenance  operations 
has  been  made  available  to  the  KADAM 
project  by  Martinair  Holland  and  KIK 
Royal  Dutch  Airlines,  the  operators  of 
the  aircraft. 

The  primary  airconditioning 
maintenance  document  utilized  in  the 
KADAM  project  is  the  Fault  Isolation  / 
Maintenance  Manual .  This  manual 
provides  Fault  Code  Diagrams 
(basically  logic  trees  of  system 
functionality)  which  are  used  by  the 
ground  engineer  to  establish  a  Fault 
Code.  The  Fault  Code  determines  which 
corrective  action  must  be  taken. 

It  should  be  noted  that  a  model  of 
system  structure  and  -functionality  of 
a  sufficient  level  of  detail  to  allow 
causal  reasoning  was  not  envisioned 
for  KADAM  because  the  effort  required 
would  be  of  prohibitive  scope.  In 
addition,  the  functional-  and 
structural  relations  that  could  be 
determined  using  the  model  are  already 
generated  for  maintainability  and 
reliability  analysis  purposes  during 
system  design.  The  results  of  these 
analyses  are  implicit  representations 
of  system  structure  and 
functionality.  One  of  the  secondary 
objectives  was  to  determine  whether 
these  implicit  representations  of 
system  structure  and  functionality 
could  be  utilized  to  build  a  working 
KBS. 

Operational  maintenance  information 
has  been  acquired  through  involvement 
of  a  member  of  the  project  group  in 
the  maintenance  organisation.  The  main 
objective  of  this  period  was  to 
identify  diagnosis  methods  as  utilized 
by  ground  engineers.  At  the  central 
maintenance  support  center  of  the 
airline  all  complaint  slips  are  kept 
on  file  for  later  reference.  A  survey 
of  the  slips  concerning 
airconditioning  complaints  provided 
insight  in  complaint  descriptions, 
complaint  histories,  failure 
distributions,  etc.  Participation  in 
the  maintenance  activities  of  ground 
engineers  enabled  an  assessment  of 
operational  aspects  of  maintenance  and 
the  diagnostic  procedures  applied  by 
experienced  maintenance  personnel .  One 
of  the  methods  employed  in  order  to 
identify  methods  was  by  means  of 
scenario's.  Scenario's  are  virtual 
complaints,  prepared  1;^  the  project 
team,  which  were  presented  to  an 


experienced  ground  engineer  in  a 
format  identical  to  a  normal  conplaint 
slip.  The  engineer  was  asked  to 
diagnose  the  complaint  and  to 
contemplate  on  the  thought  process 
behind  the  diagnosis. 

In  addition,  a  large  number  of  slips 
covering  five  years  of  operation  with 
a  fleet  of  five  aircraft  were  reviewed 
by  a  member  of  the  project  group 
together  with  a  senior  ground  engineer 
in  order  to  infer  the  diagnostic 
reasoning.  Since  related  slips  (of  a 
re-occuring  complaint)  were  grouped 
together,  it  was  also  possible  to 
assess  the  differences  in  the 
diagnoses  as  a  result  of  the 
availability  of  the  coirplaint  history 
in  the  form  of  subsequent  slips. 


5.  ANALYSIS 

5.1  Diagnosis  Methods 

One  of  the  objectives  of  the  KADAM 
project  was  to  identify  and  formalize 
diagnosis  methods.  These  methods  may 
be  generally  applicable,  hence  could 
be  used  in  other  applications.  This 
activity  not  only  created  a  frame  work 
for  the  knowledge  based  system,  it 
also  facilitated  the  recording  of 
maintenance-  and  diagnosis  experience. 
Analysis  of  the  interviews  on  the 
scenario's  and  slips,  showed  that 
particular  portions  of  the  available 
information  and  particular  operations 
with  this  information  are  used  as 
standard  elements  of  the  diagnostic 
process . 

These  elements  and  the  relations 
between  these  elements  are  combined 
and  utilized  by  the  ground  engineers 
in  several  different  ways,  depending 
on  the  operational  situation  and  the 
available  informat ion. Three  different 
diagnosis  methods  can  be  identified 
which  do  not  only  differ  with  regard 
to  the  elements  utilized,  but  also  in 
the  relations  between  the  elements. 
Not  all  elements  and  relations  are 
used  for  each  of  the  three  methods.  A 
summarized  description  of  the 
elements,  relations  and  methods  is 
provided  l^elow.  For  a  full  description 
refer  to  (Piers  and  Donker,  1989.). 

Observables:  all  information  related 
to  system  condition  that  is  available 
or  can  be  made  available  on  the 
aircraft  for  diagnosis  . 

Symptoms:  all  Observables  which  are 
related  to  an  event  that  results  in  a 
ccxnplaint.  A  failure  may  induce 
Sypmtcxns . 

Hypothesis:  a  mental  representation 
(of  the  ground  engineer)  concerning  a 
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possible  Cause  of  the  occurring 
Observetbles . 

Causes:  events,  states  or  conditions 
vdiich  result  in  Observables. 

Knowledge:  the  aggregate  of  system- 
structure  and  -functionality  knowledge 
(declarative),  knowledge  from 
experience  (heuristic)  and  Icnowledge 
of  the  history  of  a  complaint. 

Conc>are:  an  operation  in  which 
information  resulting  from  different 
elements  but  concerning  the  same 
subject  is  related  to  each  other. 

Solution:  4m  action  which  eliminates  a 
Cause . 

Test:  an  action  which  determines 
whether  the  Syn^toms  still  persist 
after  the  Solution  has  been 
implemented. 

Arrows  indicate  non-specific  relations 
between  elements.  This  may  Ise  a  simple 
sequential  relation  but  also  the  fact 
that  an  element  influences  the 
relation  between  two  other  elements. 

Method  1 


Figure  2  Method  1. 

In  the  entire  spectrum  of  observables, 
soiDe  observables  do  occur  which  are 
determined  to  be  specific  to  a  failure 
(symptoms) .  From  these  synptoms,  a 
cause  is  inferred  which  is  eliminated 
(solution)  .  Then  a  test  will  be 
performed  in  order  to  conform  that  the 
symptoms  do  no  longer  occur. 

Wffih9<^  l 


Figure  3 

The  second  method 
elements  tdiich  may 


Method  2. 

is  a  sequence  of 
not  even  Ise  called 


a  diagnostic  procedure.  It  is  however 
a  way  of  solving  ccsnplaints  which  is 
applied  in  aircraft  maintenance.  This 
method  represents  the  situation  where 
there  is  no  time  to  perform  an 
elaborate  diagnosis  and  the  particular 
cot^laint  does  not  pertain  to  a 
critical  system  function.  Findings  of 
this  project  and  other  studies 
indicate  that  in  these  cases,  the 
maintenance  crew  will  select  an  action 
based  on  previously  encountered 
Observable-Solution  relations. 

Method  3 


In  short,  the  maintenance  crew  forms  a 
hypothesis  on  the  cause  of  a  complaint 
Isased  on  the  available  information. 
The  cause  hypothesis  results  from  the 
observables  and  is  Isased  on  knowledge. 
Then  the  symptoms  which  can  be 
expected  as  a  result  of  this 
hypothetical  cause  are  determined  and 
subsequently  compared  to  the 
observables  which  occurred  in  reality. 
If  the  symptoms  are  a  subset  of  the 
observables,  the  hypothesis  is  not 
negated.  If  enough  time  is  available, 
tests  are  usually  performed  to  check 
the  correctness  of  the  hypothesis. 

5.2  Diagnosis  Bottlenecks  and  the  Role 
of  Experience 

Based  on  the  information  accumulated 
and  analysed  in  the  KAOAM  project,  a 
number  of  problems  with  concern  to  the 
diagnosis  aspects  of  maintenance  have 
been  identified.  These  problems 
exhibit  a  negative  influence  on  the 
efficiency  of  maintenance. 

The  main  cause  of  diagnosis 
difficulties  is  the  information  which 
is  (not)  written  on  the  coii«>laint 
forms  by  the  flight  crew.  Frequently, 
the  minimum  information  required  for 
diagnosis  is  lacking.  For  example,  the 
flight  conditions  at  the  rooment  of 
occurence  of  the  complaint  are  not 
always  included  in  the  complaint 
description.  Because  the  possibilities 
to  simulate  flight  conditions  on  the 
ground  are  very  limited,  a 
considerable  portion  of  the  complaints 
(28%)  can  not  Ise  duplicated  on  the 
ground  (CND)  and  can  therefore  not 
effectively  Ise  solved,  nie  survey  of 
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all  slips  also  indlcatad  that  slightly 
diffsrent  descriptions  of  conplaints 
with  the  same  cause  result  in 
different  diagnosis  results  and  hence 
different  corrective  actions. 

The  accessibility  of  the  documentation 
for  system-  and  maintenance 
information  hinders  the  use  of  these 
sources  of  information.  Hanuals  are 
bulky,  refer  to  other  manuals  vAiich 
may  not  be  readily  available  and 
manuals  often  do  not  address 
conplaints  that  are  frequently 
encountered.  In  addition, 
modifications  to  aircraft  systems  are 
often  inplemented  long  before  the 
applicable  manuals  are  updated. 

A  considerable  amount  of  the  knowledge 
of  the  experienced  ground  engineer 
concerns  efficient  use  of  the 
available  manuals.  Lack  of  relevant 
experience  may  hamper  diagnosis,  in 
particular  if  conplaint  information  is 
incCTtplete  or  uncertain  and  when  the 
most  likely  cause  must  be  selected 
from  a  number  of  possible  causes.  On 
the  other  hand,  the  KADAM  project 
showed  that  a  number  of  skills 
attributed  to  experience  (heuristics) 
in  reality  concern  common  knowledge  of 
the  structure  and  functionality  of  the 
system  (declarative)  .  A  ccminon  exanple 
of  this  declarative  )u\owledge  often 
mistaken  for  heuristic  Icnowledge 
concerns  complaints  which  do  not 
require  corrective  action  because  the 
observables  mentioned  in  the  ccxnplaint 
description  are  normal  flight  phase- 
dependent  variations  in  system 
performance. 

Another  major  bottleneck  in  diagnosis 
is  the  lack  of  information  on  the 
history  of  a  conplaint.  Frequently, 
corrective  actions  vdiich  do  not  solve 
the  problem  are  repeated  when  the 
conplaint  occurs  again  because  the 
maintenance  crew  is  not  aware  of  the 
previous  maintenance  actions  related 
to  this  particular  conplaint.  This 
precludes  a  correct  perception  of 
failure  rates  of  system  c<xiponents 
which  may  be  of  inportance  to 
selecting  a  most  likely  cause  from  a 
number  of  possible  causes.  This 
problem  is  compounded  by  a  lack  of 
feedback  to  the  maintenance  crew  of 
the  results  of  shop  maintenance  on  the 
replaced  components.  The  fact  that  the 
ground  engineer  is  not  informed  about 
%(hether  or  not  the  replaced  ccoponent 
was  really  a  failed  item  and  hence  the 
cause  of  the  problem,  does  not 
facilitate  an  effective  build-up  of 
experience. 


6.  DBSKai  AND  IMPLBtBNTATION . 

Because  the  KADAM  project  is  a 


feasibility  study  the  main  objective 
of  the  project  is  to  d«nonatrate  that 
relevant  knowledge  on  aircraft 
maintenance  can  de  acquired  and 
utilized  to  inplmsent  a  proof-of- 
concept  knowledge  based  system. 
Therefore,  and  as  a  result  of  budget 
constraints,  the  project  plan  called 
for  a  decision  on  vdiich  knowledge 
would  be  inplemented  after  the 
knowledge  acquisition  phase.  It  was 
determined  to  implement  method  1  only 
since  the  information  required  is 
readily  available. 

As  shown  in  Figure  2,  this  method  uses 
the  synptom  to  arrive  at  a  cause  which 
implies  a  so-called  top  down  approach. 
Relations  of  this  type  are  usually 
derived  using  Fault  Tree  Analysis 
(FTA) ,  the  results  of  which  can  be 
found  in  the  Fault  Isolation  Manual 
(FIM)  .  Hence  the  FIM  may  be  utilized 
as  a  basis  for  implementing  Method  1. 
The  FIM  contains  implicit  Icnowledge  on 
the  structure  and  functionality  of  the 
system. 

The  design  of  the  proof-of-concept 
system  is  such  that  the  two  other 
methods,  can  be  added  later. 

Design  and  inplementation  of  the 
proof-of-concept  system  has  been  based 
on  NEXT  2  (NLR  Engineering  X-pert 
system  Tcxjlkit)  .  NEXT  2  proved  to 
possess  the  capabilities  needed  to 
meet  the  requirements.  A  diagnosis 
method  was  implemented.  Descriptive 
knowledge  on  structure  and 
functionality  are  represented  in 
f reuses,  the  problem  solving  knowledge 
was  implemented  in  production  rules. 

At  the  start  of  a  consultation  the 
user  chooses  one  of  the  three  methods 
for  the  diagnosis.  (As  mentioned 
before,  only  method  1  is  currently 
available) .  The  user  provides  some 
initial  information  a.o.  aircraft 
tailnumber,  departure  station  etc., 
(which  is  used  for  logistic  purposes 
and  to  facilitate  access  a  conplaint 
history  database)  and  an  indication  in 
which  subsystem  the  conplaint  occured. 
Thereafter,  KADAM  queries  the  user  in 
order  to  further  identify  the  specific 
conplaint.  This  process  results  in  the 
identification  of  a  Fault  Code  which 
references  to  the  Maintenance  Manual. 
If  the  user  continues  the 
consultation,  KADAM  asks  a  number  of 
additional  questions  in  order  to 
assess  which  symptoms  do  occur,  this 
may  involve  requests  from  KADAM  to 
perform  tests.  Based  on  the  synptoms 
established,  KADAM  identifies  the 
failed  component  and  also  provides  an 
overview  of  the  maintenance  task 
required  to  solve  the  problem.  In  case 
it  is  not  possible  to  narrow  the 
possible  causes  down  to  one  component. 
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th«  possibly  failsd  caii4>onsnt8  ars 
listsd  in  ordsr  of  probability. 

So  as  to  dsBonstrats  ths  ability  of 
ths  knowlsdgs  bassd  syst«n  to 
intsrfacs  with  sxtsmal  softwars  and 
databases,  the  interface  capabilities 
of  NEXT  2  have  been  used  to  perform 
caculations  with  external  FORTRAN 
algorithms  ud  to  survey  files  frcsn  an 
external  SQL  database. 


7.  TEST  AND  VALIDATION 

Validation  testing  has  recently  been 
carried  out  by  operator-  and 
manufacturer  representatives.  Although 
the  results  are  still  being  evaluated, 
the  main  outcome  is  that  the  majority 
of  the  requirements  have  been  met . 
However,  the  constraints  to  the  scope 
of  the  in^lementation  (only  method  1), 
rendered  a  system  which  exhibits  some 
of  the  shortcomings  also  encountered 
when  using  manuals  for  diagnosis  which 
is  no  surprise  since  the 
iRq;>lementation  is  based  on  the  manual. 
Of  course  the  rapid  and  easy  access  to 
the  information  provided  by  the  proof- 
of-concept  system  facilitates  a  timely 
diagnosis.  In  addition,  the  lack  of  an 
adequate  complaint  description  remains 
a  prohibitive  factor  to  effective 
diagnosis  for  the  manual  procedure  as 
well  as  the  knowledge  based  system 
supported  procedure. 


8,  FURTHER  WORK 

One  of  the  main  issues  for  further 
work  after  the  feasibility  phase  of 
the  KADAM  project  will  be  the 
implementation  of  methods  2  and  3. 
Experience  on  symptom-cause 
relationships  can  be  collected  and 
implemented  in  method  2  but  the 
relationships  are  based  on 
subjectively  perceived  failure  rates 
and  synptom-solution  relations  which 
are  not  always  supported  by  feedback 
on  correctness  of  a  maintenance 
action.  Therefore  the  validity  is 
limited  and  method  2  can  probably  be 
implemented  in  a  more  effective  way 
through  reference  to  a  valid 
component-  or  subsystem  reliability 
database  (which  incorporates  feedback 
frcxn  shop  maintenance)  and  a  complaint 
history  database. 

As  shown  in  figure  4,  method  3 
requires  knowledge  to  infer  a 
hypothesis  from  the  observables  and 
knowledge  to  predict  symptosM  from  the 
hypothetical  cause.  The  first  relation 
is  not  unlike  method  1,  potentially 
based  on  incomplete  and/or  uncertain 
information.  What  needs  to  added  to 
implwBent  method  3  is  the  second 
relation:  reasoning  from  a  cause  to 


synptoms.  The  knowledge/ informat ion 
required  to  inplement  this  relation  is 
in  many  cases  generated  during  system 
design.  The  Failure  Modes  and  Effects 
Analysis  (FMEA)  is  a  bottom  up 
analysis  which  is  used  to  determine 
the  effect  of  conponent  failures  on 
system  functions.  (Note  that  this  is 
basically  the  reverse  of  the  FTA) . 
Based  on  knowledge  of  the  functional - 
and  structural  relations  of  the  system 
every  possible  component  malfunction 
is  evaluated  for  its  effect  on  system 
functioning,  which  means  that  the 
synptoms  of  the  failure  are  predicted. 
Consequently,  this  information  can  be 
used  to  implement  method  3 . 

The  FMEA  of  the  Fokker  100 
airconditioning  system  was  however  not 
available  in  a  format  which  could  be 
used  in  the  KADAM  KBS  without  a  major 
conversion  effort.  This  fact  bears 
another  general  observation:  a 

considerable  2unount  of  the  information 
required  to  build  a  KBS  for  system 
diagnosis  is  readily  available  or  can 
be  made  available  with  relatively 
little  effort  during  system  design. 

If  however,  the  utilisation  of  design 
analysis  (intermediate)  results  for  a 
KBS  is  not  foreseen  during  design,  the 
required  information  may  not  he 
preserved  at  all  or  may  be  generated 
in  a  format  which  does  not  facilitate 
its  use  for  a  KBS. 


9.  CONCLUSIONS 

The  main  conclusion  of  the  KADAM 
project  is  that  knowledge  of  the 
structure  and  functionality  of  a 
coitplex  system  can  indeed  be 
implemented  in  a  Itnowledge  based 
system  which  provides  useful  support 
for  diagnosis.  The  Icnowledge  used  to 
)3uild  the  KBS  is  generated  during 
aircraft  system  design  and  is 
inplicitly  available  in  the  results  of 
maintainability  and  reliability 
analyses.  The  KADAM  project  also 
demonstrated  that  experience  based 
methods  for  diagnosis  as  applied  by 
maintenance  personnel  can  be 
identified,  formalized  and 
implemented.  The  role  of  experience  in 
these  methods  can  be  identified  and 
formalized.  It  was  shown  that  a 
considerable  portion  of  maintenance 
skills  which  are  attributed  to 
experience  are  in  fact  based  on 
declarative  )uiowledge  %^ich  is 
implicitely  available  in  the  proof -of- 
concspt  )uiowledge  based  system  such  as 
flight  phase  dependent  valid  ranges  of 
performance  parameters  and  effective 
use  of  manuals.  Experience  in  the  form 
of  'tricks  of  ths  trade*  such  as 
alternative  ways  of  finding  synptoms 
can  )3e  identified  formalized,  txit 
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direct  integration  with  methods  1  and 
3  may  not  be  advisable  and  result  in 
inconsistencies,  the  experience  should 
be  validated  first. 

A  further  conclusion  does  not  directly 
concern  the  knowledge  based  system 
itself  or  its  devslq^^nent  but  the 
CCTi^laint  information  available  for 
diagnosis.  If  insufficient  complaint 
information  is  available,  in 
particular  with  regard  to  flight 
conditions,  system  configuration  and 
syn^toms  at  the  moment  of  occurence  of 
a  complaint,  an  effective  diagnosis  is 
often  precluded.  Providing  complaint 
information  is  primarily  a  task  of  the 
flight  crew.  Filling  out  a  complaint 
form  may  interfer  with  cockpit  duties 
and  essential  information  is  often 
omnitted.  A  knowledge  based  system  is 
not  likely  to  reduce  this  problem. 
Obviously,  on-board  monitoring  systems 
could  provide  valuable  information  in 
this  realm. 

A  final  finding  of  the  KADAM  project 
which  has  also  been  shown  in  other 
studies  is  that  a  limited  availability 
of  information  on  complaint  history 
may  cause  duplications  of  faulty 
maintenance  actions.  A  knowledge  based 
system  can  provide  access  to  a 
complaint  history  database  and  take 
complaint  history  into  account  when 
selecting  a  cause  from  a  number  of 
possible  causes. 
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Discussion 

I.  B.  Tarhan,  Turkey 

What  is  your  method  for  fault  isolation  which  is  not 
observed  by  ground  crew  people? 

Author; 

KADAM  KBS  is  used  for  troubleshooting  of  complaints 
occurring  during  operational  use  and  reported  by  the  flight 
crew  or  observed  by  maintenance  crews  during  turn¬ 
around/pre-flight.  Faults  not  reported  are  not  addressed.  If 
a  fault  reported  by  the  flight  crew  can  not  be  duplicated  on 
the  ground,  for  example  because  flight  conditions  can  not  be 
simulated,  KADAM  will  still  support  diagnosis  ba.sed  on 
complaint  description. 
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1  1.  SUMMARY 


Embedded  Avionics  Systems  for  aircraft  are 
becoming  increasingly  more  complex.  Very  High 
Speed  Integrated  Circuits  (VHSIC)  and  semi-custom 
devices  are  used  to  gain  many-fold  increases  in 
processing  ]X>wer  and  capability.  Mission  and 
operational  requirements  dictate  a  high  availability 
and  fault  detection  capability  defined  quantitatively 
as  ninety-eight  percent  detection  of  all  faults  and 
isolation  of  ninety  percent  of  those  faults  to  a  line 
replaceable  module  (LRM),  Or  ninety-five  percent  of 
the  faults  to  two  LRMs.  The  Integrated 
Communications,  Navigation,  Identification 
Avionics  (ICNIA)  program  utilizes  a  module 
Maintenance  Node  (MN)  which  aids  high  speed 
testing  of  the  LRM,  and  gives  the  ability  to  isolate  the 
fault  (s)  to  one  or  more  modules.  The  MN  uses  the 
concepts  of  set  scan  design,  pseudo-random  test 
vector  generation,  output  response  compression,  and 
separate  set  scan  loops  to  test  the  Small  Scale 
Integration  (SSI)  -  Medium  Scale  Integration  (MSI) 
logic  on  the  LRM.  The  resultant  data  is  made 
available  to  the  expert  system  within  ICNIA  so  that 
real-time  fault  detection  and  isolation  can  be 
achieved. 


The  objective  of  the  expert  system  within  ICNIA  is  to 
detect  and  isolate  faults  in  near  real-time  and 
minimize  the  false  alarm  rate.««]^e  technical 
approach  is  to  utilize  Built-In-TesttB(T)  as  the  data 
collection  mechanism  for  the  expert  sy>*^.  BIT 
commands  the  resources  to  perform  onlinb>^d 
offline  test  via  MNs  and  reports  the  results  toHlje 
Integrated  Test  and  Maintenance  (ITM)  functionSs. 
ITM  contains  the  expert  system  and  performs  the 
fault  isolation  and  detection  using  a  forward  and 
backward  rule-based  design  in  real-time  in  the 
aircraft.  The  paycrffs  include  ninety-eight  percent 
detection  of  all  faults,  in  flight  reconfiguration, 
increased  operational  availability  and  improve 
supportability. 


Artificial  Intelligence  (AI)  is  a  rapidly  developing 
technology  which  produces  a  number  of  tools  with 
the  potential  of  solving  many  problems  that  arise  in 
complex  electronic  systems.  The  Department  of 
Defense  (DOD)  has  realized  the  importance  of  AI  in 
solving  many  of  todays  high-tech  problems  and  thus 
is  investing  in  AI  solutions. 

A  subset  of  AI  is  the  expert  system.  An  expert  system 
is  a  computer  program  that  performs  sp>ecialized 
knowledge-based  tasks.  The  Integrated 
Communications,  Navigation,  Identification 
Avionics  (ICNIA)  program  utilizes  an  expert  system 
to  employ  fault-tolerance,  reconfiguration  and 
graceful  degradation.  The  expert  system  improves 
system  readiness  and  raises  the  probability  of  mission 
success. 

3.  What  is  ICNIA? 


ICNIA  is  a  tri-Service  program  with  the  Air  Force, 
Army  and  Navy  as  participating  services.  ICNIA 
employs  advanced  state-of-the-art  technologies  to 
develop  several  Advanced  Development  Model 
(ADM)  units  that  will  be  tested  in  a  laboratory 
environment  and  undergo  flight  demonstration.  Its 
key  objectives  are  to  demonstrate  that  multiple 
Communications,  Navigation,  Identification  (CNI) 
functions  can  be  integrated  into  a  modular  airborne 
avionics  system. 

The  ICNIA  ternunal  concept  relies  on  the  use  of 
rapidly  emerging  advanced  Radio  Frequency  (RF) 
and  digital  technologies  to  provide  aircraft  pilots 
more  Q4I  availability  and  flexibility  than  ever  before. 
By  incorporating  advanced  technologies  such  ar 
Built-In-Test  (BIT)  and  reconfigurability,  the  ICNIA 
terminal  is  capable  of  maintaining  operation  through 
multiple  failures.  With  the  use  of  BIT  technology, 
in-fli^t  reconfiguration  is  possible  to  support  the 
pilot's  needs  for  different  CNI  function  priorities 
throughout  his  mission. 


2.  Introduction 

Avionics  systems  continue  to  incorporate  increasing 
amounts  of  technology  to  meet  processing  demands 
and  in  turn  the  complexity  of  these  systems  also 
increase.  With  higher  complexity,  the  cost  also 
increases  and  thus  greater  emphasis  is  placed  on 
maintainability  and  reliability.  Complicated 
equipment  means  faults  are  more  difficult  to  IcKate 
and  require  more  time  for  rqrair  and  replacement, 
which  meaiM  an  overall  dedine  in  rdiability. 


Prior  to  ICNIA,  individual  avionics  systems  were 
developed  for  each  new  requirement  resulting  in  a 
proliferatior  of  discrete  systems.  The  ICNIA  system 
consolidates  into  a  single  integrated  terminal  as 
many  as  sixteen  separate  avionics  systems,  operating 
in  the  frequency  band  from  2  MHz  to  2  GHz.  ICNIA 
is  compo^  of  a  minimum  number  of  dynamically 
reconfigurable  modular  building  blocks  which  can  be 
used  to  tailor  the  system  capability  for  particular 
mission  or  aircraft  and  will  greatly  increase  mission 
availability,  reduce  single  proint  failures;  and  greatly 
reduce  maintenance  and  consequently  Life  Cycle 
Costs. 


Before  discussing  the  fault  tolerant  and  machine 
intelligence  aspects  of  the  system  an  overview  of 
ICNIA  will  be  given.  ICNIA  is  a  complex  multi¬ 
function,  multi-processor  system  with  real-time 
processing  requirements.  Ifey  elements  to  be 
described  include  the  functional  requirements,  the 
architecture,  the  hardware  and  the  software. 


4.1  Functional  Requirements 


The  ICNIA  functional  block  diagram  is  shown  in 
Figure  2.  The  partitioning  is  broken  into  three 
groups:  the  Radio  Frequency  (RF)  group,  the  Signal 
Processing  (SP)  group,  and  the  Data  Processing  (DP) 
group.  This  partitioning  maximizes  the  flexibility  for 
growth  and  multiple  mission  configurations. 
Furthermore,  logistics  and  acquisition  costs  are 
minimized  through  the  use  of  common  modules 
that  makeup  the  three  groups. 


The  ICNIA  terminal  implements  a  number  of  CNI 
functions  existing  as  single,  discrete  boxes  in  the 
current  inventory  and  is  based  upon  a  distributed 
processing  architecture.  The  hardware  and  software 
that  make  up  the  ICNIA  terminal  provide  the  same 
CNI  performance  as  the  discrete  function,  plus 
maintain  an  accurate  system  health  status.  Figure  1 
shows  the  CNI  functional  requirement. 


The  integration  aspect  of  ICNIA  is  based  upon  a  set  of 
common  hardware  modules  in  which  the  CNI 
functions  are  distributed.  The  hardware  modules  can 
be  programmed  to  represent  any  combination  of  the 
CNI  functions.  If  a  hardware  module  fails,  another  is 
dynamically  reprogrammed  to  implement  the  CNI 
function.  This  dynamic  reconfiguration  guarmtees 
that  the  most  mission  critical  function  with  the 
highest  priority  is  always  available. 


SYSTEM 

niDS 

HAVEQUICK 

GPS 

SWCGMS 

UNK4 

UNK11 

FITSATGOM 

TACM 


IFF 


NAmOWBMiO 


FUNCTION 

A)  VOIIX  G  DATA 

Al  VOICE 

A1  NAVIGATION 

Al  VOICE 

DATA 

DATA 

DATA 

NAVIGATION 

NAVIGATION 

TRANSPOND 

INTERROGATE 

UHF  AM  VOICE 
VHFAMIFM  VOICE 
HFSS8  VOICE 


Figure  1  CNI  Functional  Requirements 


Figure  2  ICNIA  Block  Diagram 
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The  ICNIA  hardware  is  partitioned  into  three 
equipment  groups  and  is  based  upon  the  functional 
partitioning.  These  groups  are  the  RF  group, 
consisting  of  receivers  and  transmitters;  the  SP 
group,  made  up  of  the  high  speed  real-time 
preprocessors  and  signal  processors;  and  the  DP 
group,  utilizing  1750A  data  processors.  The 
equipment  groups  are  interconnected  via  a  network 
of  high  speed  data  buses. 

4.3.1  RF  Group 


Like  the  hardware,  the  ICNIA  operational  software  is 
highly  modular  to  supvport  maintainability, 
testability,  and  software  reuseability.  The  software  is 
divided  into  three  Computer  Program  Configuration 
Items  (CPCIs):  the  data  processing  CPCI,  the  signal 
processing  CPCI  and  the  Data  Processing  Operating 
System  (DPOS)  executive.  Like  the  hardware 
modules,  the  software  modules,  both  data  processing 
and  signal  processing  can  be  reconfigured  in  response 
to  processor  failures  and/or  changes  in  mission 
priorities.  Figure  3  shows  this  software  structure. 


The  RF  group  performs  the  transmission  and 
reception  of  the  CNl  signals.  This  group  is  divided 
into  L-Band  and  UHF/VHF  frequency  ranges.  The 
RF  group  contains  the  Antenna  Interface  Unit  (AIU), 
the  receiver  switch,  the  receivers,  and  the  Power 
Amplifiers  (PA).  The  RF  group  provides  selectable 
connections  between  the  receivers  and  the  Universal 
Matched  Filters  (UMF)  in  the  signal  processor  group. 
This  capability  provides  flexible  resource  assignment 
and  fault  tolerance. 

4.3.2  The  Signal  Processing  Group 


The  signal  processing  group  converts  the  CNI 
baseband  signals  into  digital  data.  Each  Line 
Replaceable  Unit  (LRU)  consists  of  four  UMFs,  a 
Multi-Function  Modulator  (MFM),  a  Signal  Processor 
(SP),  a  Time  Frequency  Reference  Unit  (TFR),  and  a 
Red  to  Black  Transfer  Unit  (RBX).  The  UMF 
p>erforms  baseband  phase  conversion,  demodulation, 
detection,  and  signal  acquisition.  It  sends  the 
digitized  data  to  the  SP  for  processing.  The  MFM 
performs  carrier  modulation  for  all  transmitted  CNI 
signals.  The  TFR  provides  a  stable  time  base  to 
maintain  time  synchronization.  The  RBX  interfaces 
the  RF  group  with  the  SP  group. 

4.3.3  The  Data  Processing  Group 

The  data  processing  group  performs  all  CNI 
application  processing,  ICNIA  system  management, 
integrated  test  and  maintenance,  and  aircraft 
interfacing  over  the  1553B  avionics  bus.  The  Data 
Processors  (DP)  use  a  first  generation  VHSIC,  MIL- 
STD-1750A  architecture,  and  the  software  is  written 
in  JOVIAL  and  Ada. 

4.4  Software  Architecture 

ICNIA  is  unique  among  avionics  systems  in  several 
respects.  Its  reconfiguration  capabilities  are  highly 
dependent  on  software.  In  addition  to  substantial 
data  processing,  the  system  employs  programmable 
signal  processors  which  perform  functions 
traditionally  assigned  to  dedicated  hardware. 
Processing  is  distributed  among  four  data  processors 
and  two  signal  processors.  Ea^  processing  element 
is  capable  of  performing  any  task  assigned  to  its 
resp^ve  ty^.  In  the  event  of  a  processor  failure, 
executable  code  is  reconfigured  such  that  the  highest 
priority  functions  are  assigned  to  surviving 
processors,  thereby  accomplishing  a  key  Ic5nA 
requirement  for  fault  tolerance  and  graceful 
degradation. 


91-15531 

■HIHHI 


4.4.1  Data  Processing  Software. 

Jovial  J73  and  Ada  programming  languages  are  used 
and  the  functional  elements  of  the  data  processing 
software  include:  System  Management  feftware 
(SMS),  Fault  Detection  and  Isolation  (FDD  software, 
software  reconfiguration  and  multiprocessing.  In 
lines  of  code,  the  data  processing  software  accounts 
for  more  than  two-thirds  of  the  operational  software 
of  ICNIA. 

The  systems  management  software  contains  the 
Resource  Management  (RM)  software  which  controls 
allocation  of  hardware  resources  for  mission 
planning,  real-time  modification  of  the  mission  by 
the  pilot  and  availability  of  resources  as  determined 
by  the  integrated  test  and  maintenance  function.  The 
SMS  software  also  contains  the  Terminal  Control 
(TC)  software  which  starts  and  stops  the  hardware 
and  software  resources  and  oversees  terminal 
operation. 

Software  for  the  Integrated  Test  and  Maintenance 
(ITM)  function  contains  the  machine  intelligence 
which  provides  the  fault  detection  and  isolation  to 
support  in-flight  resource  management  and 
reconfiguration  (online  test)  and  non-real-time 
testing  to  improve  the  economics  of  aviotucs 
maintenance  (offline  test).  Real-time  fault  detection 
and  isolation  is  required  because  hardware  and 
software  elements  are  reallocated  in  real-time  in 
response  to  mission  demand  and  priorities. 

4.4.2  The  Synal  Processing  Software. 

The  signal  processing  software  performs  a  variety  of 
high-speed  operations  on  incoming  and  outgoing 
signals.  A  high-^Teed  VHSIC  signal  processor  is  used 
to  meet  the  requirements  of  the  demanding  real-time 
environment.  The  signal  processor  CPO  is 
ccmiprised  of  the  executive  processing  and 
applications  software.  The  executive  and 
applications  software  use  a  macro  and  micro 
instruction  set  developed  specifically  for  the  signal 
processor. 
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This  brief  introduction  of  the  ICNIA  system 
illustrates  its  capabilities  and  its  complexities.  The 
multi-function,  multi-processor  system  operating 
under  real-time  constraints  requires  a  sophisticated 
system  to  detect  and  isolate  faiilts.  An  expert  system 
was  designed  for  ICNIA  to  achieve  the  goals  of  a  fault 
detection  rate  of  98  percent  and  a  faiilt  isolation  rate 
of  90  perc0it  to  a  single  line  replaceable  module. 


The  technology  for  in-flight  reconfiguration  of  the 
ICNIA  system  is  software-dependent,  and  is  made 
possible  by  the  Built-In-Test  capability  and  the  large 
number  of  common  modules.  BIT  allows  the  system 
to  constantly  measure  its  health  status  and  to 
reassign  or  reconfigure  modules  when  a  failure  is 
detected.  The  automatic  reconfigurability  feature 
makes  the  system  fault  tolerant  and  increases  the 
mean-time-between-critical-failure  (MTEtCF). 

BIT  technology  plays  a  major  role  in  a  fault  tolerant 
design.  Furthermore,  an  expert  system  is  required  to 
handle  and  correctly  interpret  the  data.  The  expert 
system  within  ICNIA  is  called  the  Integrated  Test  and 
Maintenance  (ITM)  function  and  is  the  "brain"  for 
fault  detection  an  isolation.  The  ICNIA  BIT 
capability  consists  of  hardware  and  software  sensors 
wfuch  provide  system  health  status  information  to 
the  ITM  function.  One  of  the  key  sensor  elements  in 
the  ICNIA  design  is  the  Maintenance  Node  (MN) 
which  is  the  focal  point  for  performing  the  board 
level  tests  supporting  the  integrated  test  and 
maintenance  philosophy  of  ICNIA. 

The  ICNIA  BIT  concept  of  operation,  types  of  BIT,  the 
BIT  architecture,  the  Maintenance  Network,  and  the 
Integrated  Test  and  Maintenance  function  will  be 
developed  in  the  following  sections. 


Figure  4  illustrates  the  BIT  concept  of  operation. 
During  normal  terminal  operation,  the  hardware 
and  software  status  indicators  are  polled  by  the  ITM 
function  to  monitor  the  system  integrity  (nominally 
once  per  second).  Upon  detection  of  a  system  error  or 
processing  failure,  the  BIT  fault  indicators  are 
accumulated  and  compared  against  a  threshold. 

When  a  processed  BIT  indicator  exceeds  a  predefined 
threshold,  a  reaction  is  triggered  by  ITM.  This 
reaction  usually  consists  of  jjerforming  more  tests. 


Reactions  are  dependent  on  the  criticality  of  the  BIT 
indicator.  The  two  primary  actiorts  taken  by  ITM 
include  replace  the  asset  from  the  availability  pool 
and/or  perform  offline  tests  on  the  removed  asset. 


The  use  of  extensive  online  and  offline  BIT  allows 
the  ICNIA  terminal  to  be  supported  with  two  levels 
of  maintenance  (organization^  and  depot)  instead  of 
the  normal  three  levels.  An  indicator  is  provided  on 
LRMs  which  identifies  a  failure  so  that  a 
maintenance  technician  knows  which  LRM  to 
remove  and  replace. 


To  alleviate  the  traditional  problem  of  being  unable 
to  reproduce  a  flight  failure  after  the  unit  has  been 
returned  to  the  depot,  the  ICNIA  BIT  design 
incorporates  a  health  status  memory  function  which 
is  utilized  by  the  maintenance  node  on  the  LRM. 

The  critical  data  parameters  stored  in  the  memory 
can  be  analyzed  to  aid  the  depnjt  technicians  in 
troubleshooting  the  failed  unit.  The  health  status 
messages  are  correlated  with  time  to  enable  this 
memory  to  act  as  a  fault  history  file. 


Figure  4 


BIT  Concept  of  Operation 
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5.2  Types  of  BIT 

The  four  major  typ>es  of  BIT  implemented  in  ICNIA 
are  Online,  Offline,  Thread,  and  Standalone  BIT. 

5.2.1  Online  BIT 

Online  BIT  is  the  process  in  which  system  health 
information  is  collected  while  a  hardware  resource  is 
operational.  This  process  is  performed  passively 
leaving  the  resource  available  for  performing  0^1 
functions  and  does  not  affect  the  state  of  any  of  the 
hardware  registers,  queues,  or  memories.  Online  BIT 
may  explicitly  refer  to  a  specific  resource,  or  it  may  be 
more  general,  as  in  the  case  of  the  collection  of  CNI 
status  data  on  a  given  function.  Online  BIT  is 
provided  by  both  hardware  and  software  sensors. 

5.2.2  Offline  BIT 

Offline  BIT  is  the  process  where  data  is  collected  on  a 
hardware  resource  while  it  is  unavailable  for  a 
mission  function.  The  testing  may  reset  the  state  of 
the  hardware  registers,  queues,  or  memories.  Offline 
BIT  is  carried  out  during  system  startup,  and  during  a 
mission  after  a  system  problem  has  been  identified 
through  the  online  BIT  process. 

5.2.3  Thread  BIT 

Thread  BIT  is  the  process  of  testing  two  or  more 
hardware  modules  in  cascade  to  determine  system 
integrity/mission  readiness  or  to  perform  fault 
isolation.  Thread  BIT  performs  three  functions: 

(1)  Support  initialization  testing  of  the  system  to 
determine  mission  readiness,  (2)  Monitor  the  health 
of  operational  CNI  threads,  (3)  Support  fault 
isolation.  Thread  testing  is  not  a  primary  means  of 
fault  isolation  or  fault  detection.  Thread  testing  is 
simplistic  and  helps  to  support  the  overall  fault 
tolerant  design. 


5.2.4  Standalone  BIT 

Standalone  BIT  is  the  process  of  collecting  data  while 
the  entire  terminal  itself  is  not  being  used.  It  occurs 
only  when  the  terminal  is  not  processing  CNI 
signals.  Standalone  BIT  is  used  for  more  rigorous 
fault  isolation  testing  than  can  be  performed  in  the 
other  three  modes. 

5.3  ICNIA  Built-In-Test  Architecture 

Figure  5  provides  a  top-level  view  of  the  ICNIA  BIT 
architecture.  The  best  way  to  describe  this 
architecture  is  to  divide  it  into  three  sections:  the 
central  intelligence,  the  communications,  and  the 
sensors. 

The  central  intelligence  is  the  expert  system  which 
makes  decisions  concerning  resource  health  based  on 
BIT  indicators  and  system  rules.  The  central 
intelligence  lies  within  the  integrated  test  and 
maintenance  (ITM)  software  function  which  is  part 
of  the  Data  Processor  CPCI. 

BIT  communications  are  carried  out  via  the  high 
speed  bus,  the  Bus  Interface  Units  (BIUs),  the  serial 
maintenance  bus,  the  1553  avionics  bus,  and  the 
software  BIT  functions.  The  Maintenance  bus  is 
primarily  used  for  system  initialization,  set  scan  and 
intercoimect  testing  and  results  reporting. 

The  sensors  in  the  ICNIA  BIT  architecture  are  the 
local  hardware  and  software  elements  which  detect 
faults  or  collect  local  status  and  performance  data. 
The  key  sensor  element  in  the  ICNIA  design  is  a 
logical  device  termed  the  Maintenance  Node  (MN). 
Digital  modules  in  ICNIA  contain  a  Maintenance 
Node  which  initialize  the  module  and  execute  set 
scan  and  interconnect  test  of  logic  devices.  These 
module  tests  are  invoked  under  conunand  of  a 
Maintenance  Protocol  Processor  (MPP). 
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Figure  5 


ICNIA  BIT  Architecture 
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5.4  Maintenance  Network 

The  Maintenance  Network  designed  into  the  ICNIA 
terminal  provides  a  special  purpose  BIT  data 
collection  and  conununication  system.  The 
Maintenance  Network  architecture  is  made  up  of; 
Maintenance  Nodes  (MNs),  residing  on  digital 
modules;  a  Maintenance  Protocol  Processor  (MPP), 
which  resides  on  the  DP  serial  I/O  module  (and  acts 
as  the  Maintenance  Bus  controller);  and  the  dual 
redundant  Maintenance  Bus  which  links  the 
Maintenance  Nodes  with  the  MPP. 

5.4.1  Maintenance  Node 

The  Maintenance  Node  is  the  focal  point  for 
performing  the  board  level  test  supporting  the 
integrated  test  and  maintenance  philosophy  of  the 
ICNIA  system.  The  MN  performs  the  following 
activities: 

It  conducts  externally  controlled  offline 
board/chip  level  tests  and  stores  the  results  in 
EEPROM. 

It  sends  both  board  and  chip  level  test  results 
to  the  Maintenance  Protocol  Processor. 

It  stores  status  md  parameter  values  used  by 
devices  on  a  board  for  normal  operations. 

It  stores  online  board  fault  status  information 
and  the  time  of  fault  occurrences  in  EEPROM. 

The  MN  (in  the  offline  mode)  exercises  individual 
VHSIC,  standard  cell,  and  gate  array  (GA)  chips,  as 
well  as  Small  Scale  and  Medium  (SSI/MSI)  logic 
(74xx/54xx  logic)  configiirations  confined  to  one 
board  or  module.  The  method  utilized  is  the  "set 
scan  loop"  technique.  This  method  is  carried  out  by 
generating  multiple  test  vectors  using  an  internal 
Pseudo-Ri^dom  Sequence  Generator  (PRSG)  and 
inputting  the  vectors  in  order  to  stimulate  a  device. 

It  then  reads  the  response,  compresses  the  results 
(Signature)  vnth  a  Signature  Analyzer  (SA),  and  then 
compares  the  generated  signature  to  a  previously 
stor^  "good"  signatme  for  determining  operational 
status  of  the  tested  device. 

5.4.2  Maintenance  Protocol  Processor 

The  Maintenance  Protocol  Processor  serves  as  the 
interface  between  the  ICNIA  17S0A  Data  Processor 
and  the  Maintenance  Nodes  distributed  throughout 
the  system.  The  MPP  receives  test  commands  from 
the  DP,  via  the  DP's  input-output  processor  (lOP), 
then  formats  and  transmits  the  commands  to  the 
appropriate  Maintenance  Nodes.  In  addition,  the 
MPP  serves  as  the  Maintenance  Bus  controller.  In 
this  role,  the  MPP  distributes  all  test  commands 
(originating  from  the  DP)  and  is  responsible  for 
commanding  MNs  to  transmit  over  the  bus. 

6.  INTEGRATED  TEST  AND  MAINTENANCE 

As  mentioned  before,  the  ICNIA  "brain"  for  fault 
detection  and  isolation  is  the  FTM  function,  which 


is  part  of  the  data  processing  CPCI.  ITM  evaluates 
status  and  test  residts  in  order  to  detect  and  isolate 
faults.  One  of  the  key  requirements  of  the  FTM 
fimction  is  to  filter  and  smooth  BIT  sensor 
information  so  that  fault  false  alarms  can  be 
minimized.  The  implementation  of  the  ITM  BIT 
fault  isolation  algorithms  takes  the  form  of  a  rules 
based  system. 

FTM  is  designed  to  make  decisions  using  a 
knowledge  base  which  is  augmented  by  correlation 
of  BIT  results  and  other  status  data  generated  by 
the  hardware  and  software.  FTM  decisions  are 
based  on  a  foundation  of  basic  rules  derived  from 
the  physical  properties  of  the  hardware  and  the 
mathematical  properties  of  the  CNI  algorithms. 

6.1  ITM  Overview 

The  FTM  design  implements  an  artificial 
intelligence  expert  technique  known  as  fact  based 
inferencing.  Fact  based  inferencing  makes  decisions 
concerning  fault  detection  and  isolation  in  a 
comprehensive  and  accurate  manner  by  deferring 
decision  until  all  the  required  facts  have  been 
compiled.  For  example,  if  a  hardware  module  is 
suspected  of  failing,  a  typical  response  by  FTM  is  to 
request  further  testing  so  that  more  comprehensive 
reports  (facts)  can  be  gathered.  The  driving  reason 
that  fact  based  inferencing  was  chosen  for  the  FTM 
design  is  that  this  technique  accomplishes  fault 
detection  and  isolation  with  near  100  percent 
accuracy.  This  level  of  accuracy  mandates  a  design 
that  provides  complete  fault  coverage  as  opposed  to 
making  uncertain  decisions  quickly. 

Since  fact  based  inferencing  requires  additional 
testing,  ITM’s  response  cannot  be  provided  in  real¬ 
time.  However,  detecting  faults  quickly  is  important 
if  the  system  is  to  remain  opera^onal  during  critical 
use  periods.  Because  of  this,  a  double  inference 
architecture  was  developed  for  ITM  which  uses  a 
forward  chaining  inference  to  identify  hardware 
suspected  of  having  a  fault,  and  a  backward  chaining 
inference  which  establishes  credibility  of  a  particular 
hardware  component  by  gathering  additional  facts. 
Forward  chaining  is  fast,  but  uses  extensive  memory, 
while  backward  chaining  is  slow  and  uses  moderate 
amounts  of  memory.  Typically,  the  actions  that 
backward  chaining  requests  consist  of  tests  which  are 
disruptive  to  the  normal  hardware  operation,  so  they 
must  be  done  offline. 

6.2  Software  Architectural  Overview 

The  FTM  and  BIT  fault  isolation  software  is  organized 
into  two  major  divisions.  The  first  is  the  generic 
Built-In-Test/Fault  Isolation  (BIT/FIT)  Kernel  which 
contains  the  inference  algorithms,  and  the  second  is 
the  ITM  and  BIT  Shell.  The  FTM  and  BIT  Shell 
Software  are  designed  to  have  a  clear  cut  division 
between  the  generic  {>ortions  and  the  system  specific 
portions.  The  Shell  is  functionally  divided  into  two 
parts.  The  first  part  is  called  the  Generic  Shell 
software,  and  the  second  is  the  IGNIA  Specific  Shell. 
The  term  generic  is  used  to  mean  "not  specific  to  a 
particular  hardware  set".  The  design  produces  a 
complete  fault  detection  and  isolation  package 
capable  of  being  used  in  any  hardware  system  while 
minimizing  the  amount  of  programming  required  to 
develop  the  system  specific  portions  of  code.  Figure  6 
illustrates  the  relationship  of  the  interfaces. 


The  Generic  Shell  Software  is  divided  into  three 
major  functional  units.  The  units  include  the  New 
Facts  Generator,  the  Action  Arbitrator,  and  the 
Results  Processor.  The  BIT/FIT  Kernel  performs 
most  of  the  expert  processing  in  the  fault  isolation 
process.  It  contains  a  forward  and  backward  inference 
engine  and  several  data  base  interfaces  to  the  Generic 
Shell  software.  The  interfaces  include  the  New  Facts 
List,  the  Thread  Table,  the  Suspect  List,  the  Action 
List,  and  the  Results  List.  Hgure  7  illustrates  the  ITM 
and  BIT  architecture. 
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Figure  7  ITM  and  BIT  Architecture 


Before  the  design  of  the  Integrated  Test  and 
Maintenance  software  is  presented,  an  explanation  of 
the  rules  and  the  terms  associated  with  the  rules  is 
presented. 

6.3  Rules  Language 

An  "atomic  formula"  is  the  basic  element  of  a  rule.  It 
is  a  predicate  function  which  has  a  value  of  true  or 
false.  For  the  fault  detection  and  isolation 
application,  an  atomic  formula  is  true  when  the 
associated  fault  has  been  observed.  For  example,  an 
atonuc  formula  may  be  defined  for  a  receiver  fault. 
The  predicate  function,  Receiver_Fault  is  true  (or 
observed)  if  a  fault  is  detected  for  the  receiver 
specified.  Receiver_Fault  (Receiver_X)  is  true  for 
Receiver.!  if  Receiver.Fault  was  observed  on 
Receiver.! . 


A  "rule"  is  a  statement  which  is  used  to  make 
inferences  based  on  the  state  of  the  system.  A  rule 
has  the  following  structure: 

If  (antecedent)  Then  (conclusion) 

An  "antecedent"  is  composed  of  disjunctions  and/or 
conjunction  of  atomic  formulas.  However,  the 
“conclusion"  consists  of  only  conjunctions  of  atomic 
formulas  (af).  An  example  of  a  rule  is  shown  below. 

Rule:  IF  [af!  AND  NOT  af2]  OR  af3  THEN  af4 

ANDafS 

The  antecedent  of  Rule  !  is  "[af!  AND  NOT  af2]  OR 
af3"  and  the  conclusion  is  "af4  AND  afS'. 

Atomic  formulas  are  divided  into  three  groupis: 
primitives,  intermediate  rules,  and  goals. 

"Primitives"  represent  information  supplied  by  the 
external  world.  They  only  appear  in  the  antecedent 
of  a  rule.  In  the  fault  detection  and  isolation  case,  a 
primitive  is  a  resource  status  indication  whether  a 
fault  was  detected.  An  "intermediate  rule"  is  an 
intermediate  conclusions  of  rules.  A  "goal"  is  only 
part  of  the  conclusions  of  rules.  It  is  the  end  result. 

A  "goal”  is  only  part  of  the  conclusions  of  rules. 

The  Rules  Compiler  is  responsible  for  the  generation 
of  the  rules  tables  used  by  the  inference  engines.  The 
compiler  breaks  the  rules  into  clauses.  A  "clause"  is  a 
simple  rule  which  has  only  conjunctions  of 
primitives  in  its  antecedent  and  conjunctions  of 
goals  in  its  conclusion.  The  Compiler  eliminates  all 
intermediate  states  or  intermediate  rules,  leaving  a 
clause  logic  tree  with  a  depth  of  one  (rules 
traiTsformed  in  this  way  are  said  to  be  in 
"conjunctive  normal  form").  Thus,  the  compiler 
does  the  bulk  of  the  rule  tree  processing  and  the 
engines  are  able  to  derive  goals  directly  from  "anded” 
combinations  of  primitives,  eliminating  the  need  for 
a  tree  search. 

6.4  BIT/FTT  Kernel  Software  Overview 

The  BIT/FTT  Kernel  Software  is  composed  of  the 
Forward  and  Backward  Inference  Engines,  and  a  Fact 
Processor  that  handles  the  input  to  the  inference 
engines.  The  external  interfaces  with  the  inference 
engines  are  implemented  via  data  structures.  These 
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data  structures  consist  of  the  Rule  File  (input),  the 
Active  Thread  Tables  (input),  the  New  Facts  List 
(inpuO,  the  Action  List  (output)  and  the  Results  List 
(output).  Kgure  8  gives  a  Wgh-level  view  of  the 
inference  algorithm  architecture  with  its  external 
interfaces. 


Figure  8  Inference  Algorithm  Architecture 


Figure  8  shows  that  the  internal  interfaces  can  be 
separated  into  two  types  of  data  structures,  rule  data 
and  fact  data.  The  rule  data  is  the  interface  between 
the  Rules  Compiler  and  the  inference  engines.  This 
data  consists  of  the  Detection  and  Action  Cause 
Tables,  and  the  Detection  and  Action  Clause  Mapping 
Matrices  (these  tables  are  a  representation  of  the  niles 
in  what  is  called  "normal  conjunctive  form",  that  is, 
a  rule  transformed  into  strings  of  "anded  " 
primitives  "ored"  together).  The  fact  data  provides 
the  interface  between  the  Fact  Processor  and  the 
inference  engines.  This  interface  contains  the 
Detection  Primitive  List,  the  Detection  and  Action 
Primitive  Status  Buffers  and  the  Backward  Engine 
Start  Flag.  The  interface  to  a  specific  application  is 
accomplished  with  the  rules  in  the  Rule  File  and  the 
Action  Thread  Tables.  These  data  structures  will  be 
discussed  later. 

The  Fact  Processor  receives  the  new  system  facts, 
determines  their  types  (detection  or  isolation)  and 
forwards  them  to  the  appropriate  irderence  engine. 

A  new  system  fact  may  be  a  changed  detection  or 
isolation  primitive. 

The  Forward  Chaining  Inference  Engine  processes 
new  detection  primitives  (online  system  status). 
Based  on  this  iidormation  and  the  rule  data,  it 
generates  a  list  of  system  resources  suspected  to  have 
caused  the  error. 

The  Backward  Chaining  Iiderence  Engine  processes 
the  list  of  suspects  generated  by  the  Forward 
Chaining  Engine.  It  proves  each  suspect  to  be 
functional  or  faulty  based  on  action  results  and  rule 
data.  Action  results  are  received  in  isolation 
primitives  that  are  put  by  Fault  Detection/Fault 
Iscriaticm  (FD/FI)  onto  the  New  Facts  List.  An 


isolation  primitive  represents  that  state  of  a 
diagnostic  test  or  interrogation  request  by  the 
Backward  Engine  during  a  previous  cyde.  The 
requested  action  is  intended  to  determine  the  health 
status  of  a  resource. 

Some  assumptions  and  limitations  are  assodated 
with  the  inference  engine  architecture.  The  first 
assumption  is  that  though  statusing  may  occur 
frequently,  only  primitives  whose  values  have  , 
changed  are  reported  to  the  New  Fact  List  Secondly, 
the  inference  ^gorithms  operate  on  Boolean  values 
only.  Thus  status  obtained  in  other  forms  must  be 
transformed  to  Boolean  representations  to  be  used. 
Another  limitation  deals  with  thresholding  and 
aging.  In  fault  detection  and  isolation  applications, 
the  resource  status  information  may  be  provided  in 
the  form  of  fault  indicators  or  counters.  Usually,  a 
fault  is  processed  inunediately  up>on  being  reported 
to  the  diagnostic  and  test  system.  However,  some 
faults  may  require  a  threshold  (i.e.  a  number  of  faults 
detected  in  a  sp^edfied  length  of  time)  before  the  fault 
is  processed  as  an  actual  error.  The  assumption  was 
made  that  thresholding  is  performed  externally  to 
the  inference  engines.  The  engines  exjject  status 
information  consisting  of  fault  indicators  such  that  a 
fault  is  only  indicated  if  its  thresholding  requirement 
has  been  met.  Finally,  the  assumption  is  made  that 
active  signal  threads  are  repwrted  to  the  Active 
Thread  Tables  as  signal  paths  are  defined  or 
reconfigured.  Maintaining  these  tables  is  essential 
for  the  unification  process  that  is  necessary  when 
predicate  atomic  formulas  are  used  in  the  rules. 
Unification  is  the  determination  of  the  specific 
resource  to  which  the  predicate  atomic  formula  is 
referring. 

6.5  Fact  Processor 

The  Fact  Processor  is  a  preprocessor  for  the  inference 
engines.  It’s  main  function  is  to  update  fact  data  in 
the  system,  and  notify  the  appropriate  inference 
engine  when  inferencing  is  necessary. 

6.5.1  Data  Structures 

The  New  Facts  List  contains  all  new  fact  repwrts. 

New  facts  are  new  primitives  that  have  been 
collected  along  with  their  current  state  (fault 
observed/not  observed).  Note  that  a  primitive 
consists  of  a  typie  and  a  device  number. 

Primitive  1 

Primitive  2 
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Figure  9  New  Facts  List 

The  Detection  Primitive  List  contains  a  list  of  the 
detection  primitives  to  be  processed  by  the  Forward 
Chaining  Inference  Engine. 

Prhnitive  1 
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Figure  10  Detection  Primitive  List 
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The  Backward  Engine  Start  Flag  indicates  that  there 
are  new  isolation  primitives  to  be  processed  by  the 
Backward  Engine.  It  is  set  by  the  Fact  Processor  when 
new  isolation  primitives  are  received. 

The  Detection  Primitive  Status  Buffer  contains  the 
status  (observed,  not  observed)  of  all  detection 
primitives. 


Primitive  Type  1 
Primitive  Type  2 


Figure  11  Detection  Primitive  Status  Buffer 
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If  the  new  fact  is  an  isolation  primitive,  the  Action 
Primitive  Status  Buffer  is  updated  and  the  Backward 
Engine  Start  Flag  is  set.  An  update  to  the  Action 
Primitive  Status  Buffer  consists  of  updating  the  state 
field  of  the  isolation  primitive. 

6.6  Forward  Chaining  Inference  Engine 

The  Forward  Chaining  Inference  Engine  uses  rules  to 
generate  a  list  of  resources  suspect  to  be  bad. 
Therefore,  the  conclusion  of  each  rule  is  a  list  of  one 
or  more  resources  which  are  suspected  to  be  faulty. 
This  conclusion  is  based  on  the  current  state  of  the 
antecedent's  detection  primitives  in  the  Detection 
Primitive  Status  Buffer.  If  the  specified  combination 
of  a  rule's  detection  primitives  are  true  (i.e.  the 
associated  fault  indicators  have  been  observed),  the 
rule  infers  that  the  resource  is  suspected  to  be  faulty. 


The  Action  Primitive  Status  Buffer  contains  the 
action  indicator  for  the  isolation  primitives.  The 
indicators  are  initially  set  to  "not  requested"  and  "not 
proven". 

Figure  13  shows  the  data  flow  of  the  Fact  Processor. 


6.6.1  Data  Structures 

The  Forward  Chaining  Engine  uses  several  data 
structures  to  control  its  processing.  These  data 
structures  are  listed  below  along  with  brief 
descriptions. 


Primllivs  Typ«  1 
Primitive  Type  2 


Figure  12  Action  Primitive  Status  Buffer 
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The  Detection  Primitive  List  contains  all  the  new 
detection  primitives.  A  primitive  consists  of  a 
primitive  type  and  a  device  number.  The  table  is 
illustrated  in  Figure  9. 

The  Detection  Clause  Mapping  Matrix  contains  a 
mapping  from  each  primitive  to  the  clauses  which 
include  it.  This  mapping  is  constant  for  any 
particular  rule  set,  and  is  created  by  the  Rules 
Compiler. 


Fact  Processor  Data  Flow  Diagram 
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Figure  14  Detection  Clause  Mapping  Matrix 

The  Detection  Clause  Table  contains  the  clauses  or 
simple  rules  which  infer  conclusions  (eg.,  a  resource 
is  suspected)  from  facts  (eg.,  bad  status  detected  on  a 
receiver).  This  is  a  constant  table  for  any  particular 
rule  set  and  is  created  by  the  Rules  Compiler. 
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6:5.2.  Frocessing 

When  the  New  Facts  List  is  updated,  the  Fact 
Processor  begins  processing  and  continues  until  the 
New  Facts  List  is  empty.  The  Fact  Processor  takes 
each  new  fact  from  the  New  Facts  List  and 
determines  if  it  is  a  detection  or  isolation  primitive. 
If  it  is  a  detection  primitive,  the  Detection  Primitive 
Status  Buffer  is  updated  and  the  primitive  is  moved 
to  the  Detection  Wmitive  List. 


Figure  IS  Detection  Clause  Table 

The  Suspect  List  contains  a  list  of  all  the  goals  that 
have  been  reached,  i.e.  it  contains  a  List  of  resources 
suspected  to  be  faulty,  along  with  information 
concerning  how  these  resources  came  to  be  suspected. 

The  Detection  Primitive  Status  Buffer  contains  the 
resource  status  information.  It  contains  information 
for  each  detection  primitive  in  the  system.  This 
table  is  illustrated  in  Figure  11. 
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Figure  16 


Suspect  List 


The  Active  Thread  Tables  contain  current  signal 
threads  in  the  system.  These  tables  are  shown  below. 
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Figure  17  Active  Thread  Tables 

The  Backward  Engine  Start  Flag  indicates  that  there 
are  new  suspects  to  be  processed  by  the  Backward 
Engine.  It  is  set  by  the  Forward  Engine  when  new 
suspects  are  identified. 

The  following  diagram  shows  the  relationship  of 
these  data  structures  to  the  Forward  Chaining 
Inference  Engine. 
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The  Forward  Chaining  Inference  Engine  is  designed 
to  generate  a  list  of  resoiuces  suspected  to  be  in  error 
based  on  the  detection  primitive  status  information 
provided.  The  engine's  processing  is  driven  by  the 
Detection  Primitive  list.  The  engine  selects  the  first 
primitive  in  the  list  and  uses  it  as  an  index  into  the 
Detection  Clause  Mapping  Matrix.  The  Detection 
Clause  Mapping  Matrix  maps  each  primitive  to  a  set 
of  clauses  is  "fired"  by  the  FtMTvard  Chaining 
Inference  Engine.  If  all  the  primitives  in  the 
antecedent  of  a  clause  are  true  (taking  their  possible 
negation  into  account),  then  the  conclusion  is  true 
when  its  fault  indicator  in  the  Detection  Primitive 
Status  Buffer  is  set  to  true  (observed).  A  detection 
primitive  may  be  negated  by  adding  a  "not"  in  the 
rule  directly  preceding  the  primitive.  This  means 
that  the  primitive  state  is  equal  to  false  (not 
observed)  and  will  cause  the  primitive  to  be 
processed  in  the  rule  as  if  it  was  true.  The  engine 
repeats  this  process  while  the  Detection  Primitive 
List  contains  new  detection  new  detection  primitives. 

6.7  Backward  Chaining  Inference  Engine. 

Rules  for  the  Backward  Chaining  Inference  Engine 
are  written  to  prove  a  suspected  resource  is 
functional  (go^)  or  faulty  (bad).  The  resource  is 
assumed  to  be  good.  Therefore,  the  rules  state  the 
conditions  needed  to  prove  the  resource  is  bad.  The 
antecedent  of  each  rule  contains  logical  combinations 
of  isolation  primitives  and  the  conclusion  is  one  or 
more  resources  shown  to  be  in  error. 

Isolation  primitives  are  different  from  detection 
primitives  in  that  an  isolation  primitive's  final 
value  is  not  always  known.  The  isolation  primitives 
value  is  initially  set  to  "error  not  proven".  To 
determine  an  isolation  primitive's  final  value,  an 
action  must  be  requested.  An  action  is  a  diagnostic 
test  or  interrogation  designed  to  determine  the  status 
of  a  resource.When  the  action  is  performed  and  the 
results  are  reported,  the  isolation  primitive's  value  is 
"PROVEN  false"  if  its  final  value  is  false.  This 
approach  was  developed  to  distinguish  between  a 
default  value  of  "not  proven"  (and  thus  false  until 
the  test  results  are  received)  and  a  final  value  of  false. 

To  facilitate  processing,  each  isolation  primitive  has 
two  action  indicators:  Action  Request  and  Action 
Results.  The  relationship  of  the  values  of  these 
action  indicators  to  the  value  of  the  primitive  is 
illustrated  in  the  following  table. 


ACTIVE  THREAD 
TABLES 
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Forward  Chafaifaig  InCatenoe  Engine 
Data  Flow  Diagram 
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1.  Actiem  Requested  -  indicates  whether  the  action 
has  been  requested 
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2.  Action  Result  -  indicates  if  the  action  has  been 
processed  and  the  value  of  the  isolation  primitive. 
The  value  is  as  follows; 

Proven  True  *  error  observed 
Proven  False  -  error  not  observed 
Not  Prov«i  -  assume  error  not  observed  for 
the  moment 


Suapact  Typa  1 
Suapad  Typa  2 


Ctww*  « 

CI«UM  t 

•  •  • 

C1«UM  « 

ClauM  • 

•  •  • 

• 

• 

« 

Figure  22  Action  Clause  Mapping  Matrix 


6.7.1  Data  Structures 

The  Backward  Chaining  Inferotce  Engine  uses 
several  data  structures  to  control  processing.  These 
data  structures  are  listed  below  with  brief 
descripticms. 

The  Suspect  List  contains  a  list  of  the  resources 
suspected  to  be  faulty,  along  with  information  about 
how  the  resources  came  to  be  suspected.  This  table  is 
shown  is  Rgure  16. 

The  Backward  Engine  Start  Flag  indicates  that  there 
are  new  isolation  primitives  or  new  suspects  to  be 
processed  by  the  Backward  Engine.  It  is  set  by  the  Fact 
Processor  when  new  isolation  primitives  are 
received,  and  by  the  Forward  Engine  when  new 
suspects  are  identified. 

The  Action  Primitive  Status  Buffer  contains  the 
action  indicators  for  the  isolation  primitives.  The 
indicators  are  initially  set  to  “not  requested"  and  "not 
proven".  The  Action  Primitive  Status  Buffer  is 
shown  in  Figure  12. 

The  Action  List  contains  a  list  of  requested  actions. 
Eadi  entry  has  a  field  for  the  action  type  and  the 
spedtic  device. 


Action  1 
Action  2 


Action  Typo 

Davies 

Action  Typa 

Davies 

• 

• 

• 

Figure  20  Action  List 


The  Results  list  contains  the  results  of  the  fault 
detection  and  isolation  operation,  that  is,  the  status  of 
the  resources  suspected  to  be  faulty. 


SutpMt 
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Cicwcc 

Sucpcet 
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• 

• 
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Figure  21  Reeulto  List 


The  Action  Qause  Mapping  Matrix  contains  a 
mapping  from  each  suspect  to  the  clauses  which 
could  prove  it  to  be  faulty. 

This  mapping  is  constant  for  any  particular  rule  set. 


The  Action  Clause  Table  contains  the  clauses  or 
simple  rules  which  infer  conclusions  (like  resource  is 
faulty)  from  facts  (like  set  scan  test  on  BIU  1  failed). 
This  is  a  constant  table  for  any  particular  rule  set. 
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Figure  23  Action  Clause  Table 


Rgure  24  shows  the  relationship  of  these  data 
structures  to  the  Backward  Chaining  Inference 
Engine. 
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Figure  24 

Backward  Chaining  Inference  Engine 
Data  Flow  Diagram 
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The  Backward  Chaining  Inference  Engine  begins 
pirocessing  by  building  a  whiteboard  for  each  new 
suspect  on  tte  Suspect  List.  A  whiteboard  is  used  to 
record  the  progress  in  the  verification  of  a  suspect's 
functicmality.  This  is  necessary  since  a  conclusion 
may  not  always  be  reached  in  one  inference  cycle.  A 
whiteboard  is  built  by  indexing  with  suspect  type  into 
the  Action  Qause  Mapping  Matrix,  generating  a  list 
of  clauses  which  could  prove  the  suspect  to  be  faulty. 
A  dause  status  indicator  for  each  clause  is  allocated 
in  this  area  of  memory  (the  whiteboard). 
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Next,  the  engine  begins  processing  eadt  dause  by 
attempting  to  fnove  the  dause  is  true.  To  do  thb,  the 
engiiw  must  prove  all  the  dause's  primitives  are 
true.  To  show  an  isolation  primitive  is  true  reqxiires 
that  an  actim  be  requested,  processed  and  a  true 
result  received.  The  Action  Primitive  Status  Buffer 
provides  the  current  status  of  each  primitive.  If  the 
required  action  has  not  already  been  requested,  then 
the  engine  will  place  that  action  cm  the  Action  List 
and  set  the  action  request  indicator.  If  the  action  has 
been  re(]uested,  but  the  results  have  not  been 
received,  the  engine  caimot  make  any  further 
decisions  about  that  primitive.  In  either  case, 
processing  will  move  on  to  the  next  primitive  in  the 
dause.  If  the  action  has  been  request^  and 
prcxessed,  the  final  value  of  the  primitive  is  known. 

If  one  primitive  is  proven  false  (taking  it's  possible 
negation  into  account),  the  clause  is  false  and 
prcxxssing  continues  to  the  next  dause  for  the 
suspect.  When  a  dause  is  proven  false,  the  clause 
indicator  on  the  whiteboard  is  set  to  verification 
complete  to  prevent  repetition  of  the  clause 
evaluation  on  later  inference  cydes.  If  all  of  a 
clause's  primitives  are  true  the  clause  is  true  and  the 
suspect  is  proven  to  be  faulty  . 

When  either  all  dauses  are  proven  false  or  one 
dause  is  proven  true,  the  assodated  suspect  is  added 
to  the  Results  List  with  the  appropriate  result 
(resource  gocxl/ resource  bad).  This  processing  is 
performed  for  all  suspects  on  the  Susjject  List.  After 
all  suspects  are  processed,  the  whiteboards  are  deleted 
for  which  final  results  were  found.  Figure  25 
illustrates  the  requirements  for  proving  a  suspect's 
functionality. 


SUSPECT  IS 
FAULTY 

SUSPECT  IS  1 
FUNCTIONAL  1 

1 

1 

ONE  CLAUSE  IS 
PROVEN  TRUE 

ALL  CLAUSES  I 
PROVEN  FALSE  1 

1 

i 

ALL  PRIMITIVES 

IN  CLAUSE 
PROVEN  TRUE 

ONE  PRIMITIVE 

IN  EACH  CLAUSE 
PROVEN  FALSE 

Figure  26 

Proving  a  Suspect  Faulty  or  Functional 
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6.8.1  New  Facts  Generator 

The  New  Facts  Generattn’  is  a  fact  processor 
reqxmslUe  for  collecting  new  facts  and  routing  diem 
to  the  inference  engines.  A  fault  filtering  schero 
using  thresholding  and  aging  is  performed  on  the 
facts  used  in  the  fault  detection  process. 


6.8.1. 1  Data  Structures 

The  fault  filtering  algorithm  is  implemented  using 
the  following  data  structure. 

The  Threshold  Table  contains  an  entry  for  each 
detection  primitive.  The  event  counter  is  used  to 
record  the  number  of  bad  status  events,  and  it  is 
compared  to  the  event  threshold.  The  age  counter  is 
used  in  conjunction  with  the  age  period  to  invoke 
aging  cm  the  fact  periodically.  The  aging  flag  is  used 
to  indicate  weather  aging  is  desired  during  the 
current  processing  cycle. 

The  Prefacts  List  and  the  New  Facts  List  are  identical 
in  format  and  are  illustrated  in  Figure  9. 
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Figure  26  Threshold  Table 


The  following  diagram  illustrates  the  data  flow 
through  the  New  Facts  (Generator. 


PREFACTS 

NEW  FACTS 

NEW  FACTS 

UST 

CXNERATOR 

UST 

Figure  27  New  Facts  Generator  Data  Flow 


6.8. 1.2  Processing 

Execution  starts  with  the  initialization  of  the 
Threshold  Table.The  event  and  aging  threshold 
values  for  each  primitive  are  supplied  by  an  external 
initialization  task.  Once  the  initialization  process  is 
completed,  the  task  enters  the  main  processing  loop. 
The  sequence  begins  by  waiting  for  a  timer  task  cycle 
start  indication.  Next,  each  prefact  on  the  Prefacts 
List  is  read  in  and  processed  one  at  a  time.  The  main 
processing  loop  finishes  with  an  attempt  to  age  each 
of  the  detection  facts. 

Prefact  Processing  of  isolation  facts  consists  of  simply 
writing  the  (act  to  the  New  Facts  List.  Prefact 
processing  of  detection  facts  involves  accessing  the 
Threshold  Table  to  determine  whether  a  new  fact 
should  be  generated  and  sent  to  the  BIT/FIT  Kernel. 
The  reception  of  the  prefact  is  used  to  trigger  a 
request  for  aging  to  be  performed  at  the  end  of  the 
current  processing  cyde.  If  the  prefact  indicates  a 
good  status,  no  further  processing  is  performed.  If 
the  prefect  indicates  a  bad  status  the  event  counter  is 
incremented  and  compared  to  the  event  threshold.  If 
the  threshold  has  been  exceeded  then  a  new  fact  is 
generated  and  written  to  the  New  Facts  List.  When  a 
new  fact  is  generated,  aging  of  that  fact  is  disabled  for 
that  cyde.  This  creates  some  hysteresis  in  the  new 
fact  generation  process  for  the  purposes  of  preventing 


L 
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the  event  counter  from  crossing  the  threshold  in 
bodi  directions  during  the  same  cycle. 

The  aging  process  is  performed  for  each  detection  fact 
which  has  its  aging  flag  set  in  the  Threshold  Table. 
The  flag  was  set  earlier  in  the  cycle  to  indicate  that 
online  status  information  was  received.  This  scheme 
prevents  aging  from  being  performed  on  resources 
which  have  been  proven  faulty  or  are  currently 
under  offline  test.  The  aging  algorithm  initially  sets 
the  age  counter  to  the  age  period,  and  then 
decrements  it  each  cycle.  When  it  reaches  zero,  the 
event  counter  is  decremented  and  ctunpared  to  the 
event  threshold.  If  the  threshold  has  b^n  crossed,  a 
new  fact  indicating  a  good  status  is  generated. 

6.8.2  Action  Arbitrator 

The  Action  Arbitrator  is  responsible  for  scheduling 
action  and  managing  resource  health. 

6.8.2.1  Data  Structures 

The  Action  Arbitrator  uses  the  following  data 
structures: 

The  Action  Priority  Matrix  contains  an  entry  for  each 
detection  and  isolation  primitive. 


Primitive  1  Priority 
Primitive  2  Priority 


Figure  28  Action  Priority  Matrix 

The  Action  State  Matrix  contains  an  entry  for  each 
selection  and  isolation  primitive.  Each  entry  consists 
of  a  list  of  devices  and  their  required  states  for 
execution  of  the  action. 


Primitive  1 


Primitive  2 


Figure  29  Action  State  Matrix 
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The  Resource  State  Table  is  used  to  maintain 
information  needed  by  the  Action  Arbitrator  to  make 


Resource  1 


Resource  2 


Figure  30  Resource  State  Table 
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action  scheduling  decisions.  The  state  field  is  used  to 
indicate  healthy,  faulty,  requesting  maintenance,  or 
performing  maintenance.  The  maintenance  count  is 
used  to  track  how  many  actions  currently  require  the 
resource  to  be  in  maintenance.  The  priority  field 
indicates  the  current  priority  of  an  action  using  the 
resource. 

The  Command  List  is  used  as  an  input  stream  for  a 
variety  of  messages  from  other  tasks.  Possible 
command  identifications  include  resource  failed, 
resource  healthy,  maintenance  response,  online 
status  on,  (X  online  status  off. 


Command  10 


OparaHon  Typo 
Davica  • 


Figure  31  Command  List  Entry 


The  Action  Queue  is  identical  in  format  to  the 
Action  List  given  in  Figure  20. 

The  Action  Response  List  in  identical  in  format  to 
the  New  Facts  List  given  in  Figure  9. 

The  following  diagram  illustrates  the  data  flow 
through  the  Action  Arbitrator. 
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Figure  32  Action  Arbitrator  Data  Flow  Diagram 


6.8.2.2  Processing 

Execution  starts  with  the  initialization  of  the  Action 
Priority  Matrix  and  the  Action  State  Matrix.  The 
priority  and  a  list  of  devices  and  their  required  states 
during  test  execution  are  supplied  for  each  action  or 
primitive  by  an  external  initialization  task.  Once  the 
initialization  process  has  completed,  the  task  enters 
the  main  processing  loop.  The  sequence  begins  by 
waiting  for  a  timer  task  start  of  cycle  indicaticm. 

Next,  each  acticm  is  read  off  the  Action  list  and 
inserted  into  the  Action  Queue.  Once  the  Action  List 
has  been  emptied,  the  Command  List  is  processed 
one  message  at  a  time  until  it  is  empty.  The 
Conunand  List  may  contain  such  things  as 
maintenance  request  responses,  resource  health 
reports,  or  tmline  status  enable/disable  commands. 
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After  dte  Comnuoul  List  has  been  processed,  each  fact 
<»  action  respmse  is  read  off  the  Action  Response 
List  and  processed  one  at  a  time.  This  list  is  used  in 
the  implemoitation  of  a  dosed  lo<^  action/response 
protoc^.  The  main  processing  loop  finishes  with  the 
processing  of  the  Action  Queue  and  the  initiation  of 
online  status. 


Online  status  is  initiated  simply  by  attempting  to 
schedule  all  of  the  actions  corresponding  to  detection 
primitives.  This  method  prevents  online  status 
requests  from  being  generated  for  offline  or  failed 
devices. 

6.8.3  Results  Processor 


Actions  pulled  off  the  Action  List  are  inserted  into 
the  Action  Queue  unless  them  is  already  an  identical 
queued  actkm.  The  priority  for  a  particular  action  is 
obtained  from  the  Action  Priority  Matrix,  and  it  is 
used  to  insert  an  action  into  the  sorted  queue  after  all 
of  the  actions  of  equal  or  higher  priority.  As  an 
action  is  inserted,  rruuntenance  requests  are  written 
to  the  Resources  Healfft  List  for  all  devices  listed  in 
the  Action  State  Matrix  as  requiring  maintenance. 
The  Resource  State  Table  state  and  the  maintenance 
count  are  also  updated  to  reflect  the  maintenance 
request. 

Actirm  responses  are  used  to  signal  the  completion  of 
the  executing  action.  When  a  resportse  is  received 
the  correspronding  list  of  devices  is  fetched  from  the 
ActicHt  State  Matru;.  If  a  device  is  in  maintenance 
mode,  the  maintenance  count  is  decremented  and  a 
maintenance  complete  message  is  written  to  the 
Resource  Health  List.  The  priority  field  in  the 
Resource  State  Table  is  also  cleared  to  indicate  that 
the  resource  is  tu>  longer  busy  from  the  execution  of 
the  action. 

The  Command  List  is  used  to  collect  all  of  the  inputs 
to  the  Action  Arbitrator  that  do  not  fall  into  the 
category  of  inferendng  actions  and  action  responses. 
These  inputs  include  maintenance  request  responses 
from  the  Resource  Health  Table  Manager,  online 
status  etrable  or  disable  command  from  the  Resource 
Health  Table  Maiuiger,  and  resource  health  reports 
from  the  Results  Processor. 

A  maintenance  response  from  the  Resource  Health 
Table  Maiuger  is  received  on  the  Comrtumd  List  for 
each  maintenance  request  issued.  Upon  reception  on 
their  response  the  Rewurce  State  Table  state  is 
changed  from  requesting  maintenance  to  performing 
maintenance. 

Resource  health  reports  read  off  the  Command  List 
are  used  to  update  the  Resource  State  Table  and  are 
sent  on  to  the  Resource  Health  Table  Maitager.  If  the 
maintenance  count  is  zero  for  the  resource  specified 
in  a  report  cf  healthy,  then  the  state  is  set  to  healthy. 
If  it  is  ivot  zero,  then  the  health  repwrt  is  written  back 
to  the  Cmnmand  List  to  be  prroces^  next  cycle.  If  the 
report  indicated  failure,  the  state  in  the  ReMurce 
State  Table  is  set  accordingly. 

The  Action  Queue  is  processed  from  begiiming  to 
end  by  attempting  to  schedule  each  action.  A 
particular  action  is  sdteduled  only  if  the  list  of 
devices  and  sUtes  given  in  the  Action  Priority  Matrix 
exactly  matches  the  current  state  of  the  devices  found 
in  the  Resource  State  Table  Priority  fields  for  those 
devices  indicate  that  they  are  itot  under  test  Actioiu 
are  scheduled  by  writing  them  to  the  Action 
Directive  list 


The  Results  Processor  is  respoitsible  for  the  post¬ 
processing  necessary  after  the  inference  engines  have 
either  convicted  or  acquitted  a  suspected  resource. 

6.8.3.1  Data  Structures 

The  Results  Processor  uses  one  primary  data  base  to 
store  the  special  processing  instructions  required  for 
each  resource  received  from  the  Results  List 

The  Results  Processing  Table  contains  information 
on  what  special  processing  must  be  performed  for 
each  convicted  or  acquitted  resource.  The  opcoded 
field  indicates  either  health  reporting,  error  logging, 
action  initiation,  thread  passing,  susp>ect  generation, 
good  fact  ^neration,  or  bad  fact  generation.  Each 
instruction  includes  a  pass  and  fail  tag  on  which  it's 
invocation  is  based,  such  that  all  instructions  marked 
for  pass  are  executed  when  the  result  indicated 
suspect  acquittal,  and  all  instructions  marked  for  fail 
are  execut^  when  the  result  indicates  suspect 
conviction. 
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Figure  33  Results  Procesing  Table 


The  following  diagram  illustrates  the  data  flow 
through  the  Results  Processor. 


Remilta  Proccwor  Data  Flow  Diagram 
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6.8.3.2  Processing 

Execution  starts  with  the  initialization  of  the  Results 
Processing  Table.  The  special  processing  instructions 
for  each  resource  are  supplied  by  an  external 
initialization  task.  Once  the  initialization  process  has 
completed,  the  task  enters  the  main  processing  loop. 
The  sequence  begins  by  waiting  for  input  from  the 
results  list.  The  results  list  is  an  interface  to  the 
BIT/FTT  Kernel  used  by  the  Backward  Inference 
Engine  to  report  the  convictions  and  acquittals  of 
suspects.  Each  result  is  read  in  and  processed  one  at  a 
time. 

Based  on  the  resource  designated  in  the  result,  the 
proper  group  of  special  processing  instructions  are 
extracted  from  the  Results  Processing  Table.  The  six 
types  of  special  processing  instructions  include 
reporting  resource  health  to  the  Action  Arbitrator 
Command  List,  writing  a  result  to  the  logging  list, 
writing  a  special  action  to  the  Action  List,  generating 
a  backward  inference  engine  thread  to  be  used  with 
the  next  suspect,  writing  a  suspect  to  the  suspect  list, 
and  writing  a  fact  to  the  Prefacts  List.  If  the  result 
indicates  pass,  then  an  instruction  is  executed  and  it 
is  tagged  as  pass.  If  the  result  indicates  failure  then 
an  instruction  is  executed  and  it  is  tagged  for  failure. 
The  type  and  device  number  fields  define  a  resource 
when  used  with  reporting,  logging,  thread  passing,  or 
suspecting,  and  they  define  a  primitive  when  used 
with  action  initiation  or  fact  generation. 

7.  CONCLUSION 

The  Expert  System  within  ICNIA  utilizes  a  double 
inference  architecture  for  the  Integrated  Test  and 
Maintenance  software  function.  Forward  chaining 
inference  is  used  to  identify  hardware  suspects  of 
having  a  fault,  and  backward  chaining  inference  is 
used  to  establish  credibility  of  a  particular  hardware 
component  by  gathering  additional  facts.  This  allows 
for  a  comprehensive  fault  detection  and  isolation 
system  to  isolate  95  percent  of  all  known  faults  to  a 
single  line  replaceable  unit  and  90  p>ercent  of  all 
known  faults  to  two  or  more  line  replaceable  units. 


Discussion 

1.  J.  Bart,  United  States 

How  many  rules  are  being  implemented  in  the  ICNNIA 
KBS  for  fault  tolerance? 

Author; 

The  total  number  of  rules  in  the  Expert  System  is 
approximately  300.  Two-thirds  of  the  rules  (or  200)  are  for 
the  Backward  Chaining  Inference  Engine.  More  rules  (in 
general)  are  required  for  Backward  chaining  because 
Backward  chaining  (suspect  substantiation)  is  more  difficult 
to  convict  suspects.  That  is  more  rules  are  needed  to  convict 
suspects  than  to  identify  them.  One-third  of  the  rules  (or 
100),  are  for  the  forward  chaining  inference  engine. 

2.  Prof.  A.N.  Ince,  Turkey 

As  a  result  of  integrating  communication  navigation  and 
identification  functions  what  has  been  achieved  in  terms  of 
savings  in  weight,  power  and  volume? 

Author; 

Weight  savings  from  360  lbs  to  250  lbs,  power  reduction  of 
50%,  and  size  has  reduced  from  5.0  cu.  ft  to  4  cu.  ft  based  on 
the  integration  of  these  functions  within  the  system. 
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Advatnced  avionics  systems  will  execute 
Ada  software  on  multiple  parallel 
conputers.  The  size  euid  complexity  of  the 
avionics  software  will  be  massive.  Of  « 
particular  inqportance  is  how  the  softw^cm— ^ 
will  be  supported  once  it  is  deliverpdto 
the  Air  Force-  Software  support  iy^hat 
part  of  the  avionics  software  life|^cycle 
that  deals  with  the  correction  of 
deficiencies  and  the  addition  of 
enhancements  to  the  avionics  software. 

Much  of  the  time  spent  by  personnel  is 
information  searching  and  inferencing. 

These  tasks  are  made  more  complicated  when 
information  that  was  useful  to  the 
developer  is  not  included  in  the  software 
documentation  that  is  delivered  with  the 
weapon  system 

^ This  paper  will  first  cover  the 
challenges  facing  avionics  software  support 
personnel .  It  will  address  an  advanced 
software  support  concept  called 
Development -Memory  (DM) .  This  research  is 
being  accomplished  by  the  Air  Force  Wright 
Laboratory's  Avionics  Directorate  with 
contracted  support  from  Hughes  Aircraft 
Company' s  Radar  Systems  Group .  DM  relies 


instrumentation,  workstations,  software 
tools  2tnd  documentation,  em  out-the-window 
display,  and  the  avionics  controls  and 
displays . 

The  software  that  is  supported 
executes  in  real-time  on  embedded 
computers .  The  software  source  code  is 
large  and  complex  since  it  inplements 
avionics  applications  such  as  fire  control, 
radar,  stores  management,  navigation,  and 
electronic  warfare.  In  addition,  the 
software  contains  a  vast  amount  of 
documentation  that  was  created  during  its 
development.  The  Air  Force  is  now 
developing  its  avionics  software  using  the 
Ada  Programming  Language  and  DOD-STD-2167A 
(Defense  System  Software  Development) . 
DOD-STD-2167A  describes  over  twenty 
documentation  items  that  can  be  delivered 
from  a  software  development  effort. 

For  a  typical  avionics  software  project 
these  documents  consist  of  hundreds  of 
pages,  contain  multiple  volumes,  and 
reference  other  documents .  It  is  this 
documentation  and  source  listings  that  the 
support  personnel  use  to  maintain  and 
upgrade  the  avionics  software . 


on  Machine-Intelligence  technology  in  its 

goal  to  enhance  avionics  software  support The  majority  of  the  software  life-cycle 

^  costs  occur  during  the  post  deployment 


DM  technology  refers  to  the  processes, 
tools,  and  techniques  required  for 
achieving  the  goal  of  development  knowledge 
transfer.  The  DM  will  contain  the 
motivation  and  rational  that  influenced  the 
development  of  the  software.  The  DM  and 
its  support  software  would  serve  a  large- 
scale  software  development /support  effort 
the  same  way  human  memory  serves  a  single 
individual.  Machine-Intelligence  (MI) 
technology  is  needed  for  creating  and 
utilizing  the  DM;  for  example,  the  use  of 
expert  systems,  seoiantic  networks, 
knowledge  architectures,  intelligent 
information  organization  and  retrieval 
tools.  These  Machine-Intelligence  (MI) 
aspects  will  be  discussed  in  this  paper 
within  the  context  of  the  development  and 
use  of  a  DM  based  software  support  system. 

BACKGROUND  ON  AVIONICS  30FTNARE  LOGISTICS 

Software  support  (logistics) 
activities  occur  after  the  weapon  system  is 
fielded.  The  majority  of  the  Air  Force's 
software  suiq^rt  activities  occur  at  Air 
Logistic  Centers  (ALCs) .  Typically  each 
ALC  is  responsible  for  supporting  several 
weapon  systeaw  of  the  saaie  type.  Neapon 
system  software  is  supported  by  using  an 
Integration  Support  EnvironsMnt  (ISE) .  The 
I SB  includes  the  needed  hardware  and 
software  to  analyse,  change.  Integrate, 
test,  verify,  and 'validate  the  weapon 
system's  software.  For  exaaqple,  the  ISE 
contains  the  eadSedded  avionics  coiiq>uters, 
sisnilation  models  and  cooqputers,  high-speed 
networks,  test  software  and 


support  phase  of  the  weapon  system.  With 
this  in  mind  the  Air  Force  established  a 
comprehensive  program  to  enhance  the  PDSS 
process,  called  the  Embedded  Computer 
Resources  Support  Improvement  Program 
(ESIP) .  WL/AAAF  is  responsible  for  the 
research  and  development  (R&D)  aspects  of 
ESIP.  One  contract  RSD  effort,  called 
Modular  Embedded  Computer  Software  (MECS) , 
is  with  Hughes  Aircraft  Company.  The 
objective  of  the  MECS  effort  is  to  develop 
now  technology  and  techniques  to  support 
the  maintenance  of  distributed  fault- 
tolerant,  multiprocessor  avionics  software. 

The  software  that  is  supported 
executes  in  real-time  on  embedded 
computers.  The  software  source  code  is 
large  and  complex  since  it  implements 
avionics  applications  such  as  fire  control, 
radar,  stores  memagement,  navigation,  and 
electronic  warfare.  In  addition,  the 
software  contains  a  vast  amount  of 
documentation  that  was  created  during  its 
development .  The  Air  Force  is  now 
developing  its  avionics  software  using  the 
Ada  Programming  Language  and  DOD-STD-2167A 
(Defense  System  Software  Development) . 
DOD-STD-2167A  describes  over  twenty 
documentation  items  that  can  be  delivered 
from  a  software  development  effort . 

For  a  typical  avionics  software  project 
these  documents  consist  of  hundreds  of 
pages,  contain  multiple  volumes,  and 
reference  other  documents .  It  is  this 
dociimentation  and  source  listings  that  the 
support  personnel  use  to  maintain  and 
upgrade  the  avionics  software. 
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The  majority  of  the  software  life-cycle 
costs  occur  during  the  post  deployment 
support  phase  of  the  weapon  system.  With 
this  in  mind  the  Air  Force  established  a 
coiqprehensive  program  to  enhance  the  PDSS 
process,  called  the  Embedded  Computer 
Resources  Support  Iiq>rovefflent  Program 
(ESIP) .  WL/AAAF  is  responsible  for  the 
research  and  development  (R6D)  aspects  of 
ESIP.  One  contract  R&O  effort,  called 
Modular  Embedded  Computer  Software  <MECS) , 
is  with  Hughes  Aircraft  Company.  The 
objective  of  the  MECS  effort  is  to  develop 
new  technology  and  techniques  to  support 
the  maintenance  of  distributed  fault- 
tolerant,  multiprocessor  avionics  software. 

Before  developing  2uiy  new  technology 
or  techniques,  it  was  decided  that  the 
support  process  needed  to  be  studied.  It 
was  importeuit  to  determine  what  aspects  of 
software  logistics  were  the  most  difficult 
and  consumed  the  greatest  amount  of  time. 
With  this  knowledge,  the  contract  resources 
could  be  concentrated  on  areas  that  would 
have  the  most  effect.  First,  a  discrete 
model  of  the  software  maintenance  process 
was  constructed.  "Once  the  process  model 
was  defined,  a  survey  of  20  Hughes  Radar 
Systems  Group's  tactical  software 
engineering  staff  who  had  substantial  radar 
software  maintenance  experience  was 
performed  (Figure  1) .  The  results  of  the 
survey  indicated  that  the  "information 
gathering"  consumed  the  majority  of  the 
time.  Furthermore,  "information  searching 
and  inferencing"  was  the  largest  part  of 
information  gathering  (approximately  l/5th, 
see  Figure  2) .  In  addition,  the  survey 
respondents  indicated  a  need  for  higher 
quality  information,  more  comprehensive 
documentation,  and  improvement  in  the  means 
of  locating  desired  information  within  the 
documentation. " (1) 
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Figure  2 


Hhat  the  MECS  survey  revealed  was  the 
existence  of  a  development -maintenance 
knowledge  gap.  Even  though  developers 
treuisfer  the  system  software  and 
documentation  to  the  maintainers,  their 
understanding  of  the  system  is  not 
transferred.  Knowledge  that  the  developers 
find  useful  is  not  being  recorded.  With 
the  results  of  the  survey,  research  began 
on  ways  to  reduce  the  development - 
maintenance  knowledge  gap .  One  outcome  of 
the  MECS  research  was  a  concept  of  an 
Integrated  Software  Development  Product 
(ISDP> . 

INTEGRATED  SOFTWARE  DEVELOPMENT  PRODUCT 

The  developer's  understanding  of  the 
system  is  based  on  many  documents  and  other 
pieces  of  information.  For  example, 
technical  papers,  briefings,  and  internal 
documents  help  the  developer  understetnd  the 
system  and  its  software.  Often  this 
information  is  never  included  in  the 
delivered  documentation.  When  the  system's 
software  requires  support,  maintenance 
personnel  must  retrace  the  steps  the 
developer  took  to  understanding  the  system, 
in  addition  to  recreating  information  to 
gain  the  required  knowledge.  Basically,  an 
Integrated  Software  Development  Product 
(ISDP)  will  allow  the  maintainer  to  view 
the  system  through  the  eyes  of  the  original 
developers . 

This  ISDP  will  contain  information 
normally  lost  to  software  support 
personnel .  It  provides  a  way  of 
integrating  the  information  contained 
within  the  deliverable  documents  and 
information  used  by  developers  in  creating 
the  system  into  a  single  entity.  Building 
an  ISDP  is  more  than  just  collecting 
documents  euid  linking  them  together.  It 
requires  processes,  tools,  and  techniques 
to  collect  knowledge  from  software 
developers  and  transfer  it  to  software 
maintainers .  An  approach  to  realizing  an 
ISDP  is  through  the  development  of  a 
component  called  the  Development  Memory 
(DM)  . 
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development  memory 

An  ISDP  can  be  realized  with  the 
support  of  a  DM  technology.  The  DM  involves 
an  information  architecture,  tools  for 
collecting  and  transfering  knowledge,  some 
of  which  rely  on  machine  intelligence 
techniques,  and  the  human  operator.  The 
end  result  of  using  the  DM  is  that  the 
human  appears  more  intelligent  when 
working.  Work  is  ongoing  on  the  DM.  "The 
work  is  focusing  on  making  the  DM  capable 
of  the  following: 

1)  Recording  and  storing,  for  later 
reuse,  information  pertinent  to  the 
development  process . 

2)  Allowing  for  quick  and  effortless 
access  and  comprehension  of  information 
needed  to  support  the  system." 

(2) 

Recording  software  developer 
understanding  is  not  as  simple  as  having 
the  deveroper  write  one  more  conventional 
document.  Human  memory  readily  allows  for 
the  relating  of  many  different  pieces  of 
information  in  different  ways . 

Conventional  linear  text  documents  do  not . 
Therefore  one  would  think  that  hypermedia 
documents  should  be  used  to  record  the 
developers  understcinding.  However,  this  is 
not  enough.  The  reason  is  human  memory 
automatically  places  and  maintains 
information  it  recerves  while  hypermedia 
documents  do  not  provide  this  service. 

The  DM  approach  is  motivated  by 
software  support  concerns.  However, 
developers  stand  to  benefit  from  its  use  as 
well,  since  they  will  have  the  capability 
to  access  needed  information.  The  i 

following  sections  will  discuss  the  various  I 
pieces  of  the  DM  and  highlight  the  MI 
aspects . 

DEVELOPMENT  MEMORY  KNOWLEDGE  ARCHITECTURE 

The  DM  is  intended  to  be  constructed  as  a 
result  of  the  software  development  process. 
"The  DM  knowledge  architecture  reflects  the 
hierarchical  structure  of  development 
roles.  This  structure  roughly  parallels 
the  organization  of  the  development.  A 
development  role  represents  a  part  played 
by  one  or  more  developers  in  meeting  a 
specified  development  objective. 

(Figure  3)  These  objectives  can  be  high- 
level  like  "radar  tactical  software 
development",  but  more  often  would  be  low- 
level,  such  as  "Range  While  Search  Mode 
Scan  Function  Development" ." (3) 

If  the  information  in  a  DM  is  to  be 
useful,  it  must  have  continuity  and  a 
coherent  arrangement  so  that  both 
developers  and  maintainers  can  understand 
it .  Therefore  it  is  advantageous  to  have 
the  DM  parallel  the  actual  development  in 
its  organization.  Large  scale  avionics 
software  efforts  are  organized  in  a  i 

hierarchical  fashion .  In  the  development  ' 
hierarchy,  each  development-iole  has  a 
superior  and  most  likely  one  or  more 
subordinate  development  roles .  Each  has 
specific  objectives  and  resources  assigned 
to  it  through  its  superior.  (Figure  4) 


The  organization  needs  to  address 
development -role  relationships  that  are 
established  across  hierarchical  boundaries . 
For  example,  the  development  of  avionics 
software  is  divided  into  overlapping 
efforts  of  functional  requirements 
preparation  and  software  design,  code,  and 
unit  test.  Each  major  effort  is  a  distinct 
branch  of  the  development  hierarchy. 
Development  roles  are  defined  as  preparing 
requirements  or  software  design,  code,  and 
unit  test .  "This  is  ideal  from  a 
management  perspective.  However,  for  an 
effort  to  succeed  the  branches  need  to 
directly  interact  with  one  another . 

Lateral  interactions  can  exist  within  the 
structure,  however  through  procedure  rather 
than  structure  (Figure  5)."  (4)  These 
lateral  assignments  result  in  information 
being  transferred  across  hierarchical 
boundaries . 
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Hierarchical  Organization  of  Developinent  Role 
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Hierarchical  Protocol  of  Lateral  Interactons 
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Mith  the  DM  knowledge  structure 
mirroring  the  organisation  of  the 
development  effort  the  next  area  that  will 
be  addressed  is  the  acquisition  of  the 
knowledge.  This  can  be  thought  of  as 
memorization.  Again,  this  knowledge  will 
be  organized  in  the  fashion  described 
above.  The  knowledge  acquisition  will  help 
generate  the  development  memory. 

The  question  now  arises  as  to  how  will 
the  knowledge  be  acquired  from  the 
developers .  The  DM  needs  the  knowledge 
from  the  developers  and  from  the 
development  roles  they  perform. 

"Developers  often  experiment  with  ideas 
using  paper  or  white  boards.  This  can  be 
referred  to  as  the  development  space.  When 
the  ideas  are  finalized  or  a  solution 
obtained  it  is  not  recorded  in  a  permanent 
or  organized  fashion.  To  alleviate  this 
problem  the  DM  based  system  allows  for 
experimentation  within  the  development 
space.  When  ideas  are  concluded,  the 
developer's  work  with  his  solution  is 
already  on  the  system.  The  work  can  easily 
be  edited  for  appearance  purposes  and 
transferred  to  the  DM' s  knowledge  base. "(5) 

"One  can  also  gain  critical 
information  for  understanding  the  design  of 
the  software  by  examining  the  relationship 
between  development  roles  in  the 
organizational  hierarchy.  This  information 
is  contained  within  the  assignation  space. 
Assignation  spaces  describe  the  agreed  upon 
objectives  of  the  development  role,  lists 
the  resources  and  other  items  entitled  by 
the  development  role,  and  describes  what 
the  obligations  of  the  development  role  are 
with  respect  to  other  development  roles . 
Every  development  role  within  the 
organizational  hierarchy  shares  an 
assignation  space  with  each  of  its 
subordinates.  Lateral  assignation  spaces 
also  exist  across  hierarchical  boundaries. 
This  provides  information  concerning  any 
shared  responsibilities  for  fulfilling 
design  specifications. 

The  designer's  interpretations  of  the 
specifications  are  held  in  translation 
spaces.  Translation  spaces  are  not  shared. 
They  are  meant  to  be  an  area  where 
individual  responsibilities  and  objectives 
of  a  development  role  may  be  addressed. 

The  DM  system  has  access  to  all  of  the 
translations  systems . 

The  developer  ultimately  creates 
deliverable  end  products  such  as  source 
code  and  documentation.  Each  development 
role  has  an  end-product  space  where  the 
contributions  to  the  final  product  are 
stored. " (6) 

Knowledge  of  the  system  is  contained 
within  the  development,  assignation, 
translation,  and  end-product  spaces. 
However,  knowledge  is  available  as  a  result 
of  the  interrelationship  of  the  spaces. 

The  spaces  in  which  the  developer  operates 
provides  the  motivational  inforziation  for 
the  particular  action  he  performs  such  as 
programming  a  certain  type  of  algorithm. 


Human  memory  retrieves  information  in 
response  to  the  stimuli  of  associated 
information,  conditions,  and  situations. 

Our  memories,  with  the  help  of  cues  from 
the  outside  world,  remind  us  to  do  things . 
Similarly,  developers  will  need  to  be 
reminded  frequently  to  store  significemt 
information  if  their  full  understanding  is 
to  be  captured.  The  organization  of  many 
interrelated  items  of  information  is  a 
formided>le  task.  Naturally,  the  developer 
would  find  this  undesirable  since  it  would 
interfere  with  his  or  her  work.  Automating 
this  would  help  considerably. 

What  is  needed,  in  addition  to  a 
hypermedia  styled  knowledge  base,  is  an 
active  component  that  can  perform  the 
following  services: 

1)  Assistance  in  the  timely 
placement  and  organization  of  information 
pertinent  to  the  development  process . 

2)  Assistance  in  the  timely 
retrieval  and  presentation  of  development 
memory  information. 

The  MECS  effort  devised  the  concept  of 
having  a  Development  Secretary  (DS)  provide 
these  services .  A  description  of  1  he  DS 
follows  in  the  next  section. 

DEVELOPMENT  SECRETARY  (DS) 

Recall  that  a  DS  was  conceived  to 
provide  the  active  services  of  the  DM 
described  in  the  previous  section.  The  DS 
acts  like  a  human  secretary  does  within  an 
organization.  The  DS  assists  in  the 
collection  and  organization  of  information 
without  having  to  know  all  the  technical 
details .  The  DS  uses  the  knowledge 
architecture  described  above  much  like  a 
human  secretary  uses  a  file  plan.  The  DS 
makes  uses  of  elements  from  two  MI 
paradigms  to  acquire  and  transfer 
knowledge .  The  two  paradigms  are  expert 
systems  and  semantic  networks . 

To  provide  the  services  required  by 
the  DM  the  DS  needs  a  certain  degree  of 
intelligence;  in  this  case  MI.  A  semantic 
network  is  needed  so  that  the  DS  can 
understand  what  the  user  is  doing.  A 
semantic  network  represents  language.  The 
network  is  made  up  of  nodes  that  are 
interconnected  by  arrows .  The  nodes  can 
represent  nouns  while  the  arrows  are  verbs 
that  describe  some  sort  of  action.  The 
development  of  a  semantic  network  for  the 
DS  allows  it  to  understand  what  the  user  is 
doing  for  the  development  effort .  In 
addition,  it  allows  the  DS  to  ask  what  the 
user  is  doing  if  the  action  is  incompatible 
with  the  existing  semantic  network. 

The  following  is  a  description  of  the 
OS's  semantic  network.  The  nodes  of  this 
network  cetn  be  thought  of  as  subjects, 
objects  or  both.  The  interconnections 
(arrows)  between  the  nodes  are  called 
relationships.  The  arrow's  source  node  is 
referred  to  as  a  subject.  Subjects  can 
contain  one  or  more  states .  The  arrow' s 
destination  node  is  called  an  object . 
Subject  and  objects  are  described  by  nouns 
or  modified  nouns  while  relationships  are 
described  by  verbs .  To  understand  the 
semantic  network  an  example  is  described 
below. 
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Consider  a  problem  being  worked  on  by 
a  developer.  Me  will  call  this  Problem  X. 
Problem  X  initiates  several  ideas. 
"Initiates"  is  the  relationship.  The  ideas 
which  are  the  objects  are  Idea  A,  Idea  B, 
euid  Idea  C.  In  this  example.  Problem  X 
can  be  in  the  "solved"  or  "unsolved"  state. 
The  developer  begins  to  work  on  Idea  A. 

The  DS  is  aware  of  this  and  associates  all 
work  performed  by  the  developer  to  Idea  A. 
If  the  user  moves  on  to  work  on  Idea  Y,  the 
system  is  able  to  ask  why  Idea  A  was 
abandoned,  by  using  a  simple  rule  contained 
in  the  rule  base.  When  the  user  answers 
the  question,  the  DS  can  store  it  in  the 
development  memory.  If  the  user  moves  on 
emd  begins  work  on  another  Problem,  then 
the  DS  can  ask  if  it  should  change  the 
state  of  the  problem  to  solved  from 
unsolved.  In  addition  it  will  store  the 
work  performed  on  the  idea  in  the  knowledge 
base  for  later  retrieval  by  maintenance 
personnel .  In  the  course  of  working  on 
Idea  A,  the  user  may  identify  the  idea 
possesses  a  cost  advantage.  Here  the 
network  can  be  expanded  by  the  user  telling 
the  DS  that  Idea  A  possess  an  advantage  in 
coat.  Now  Idea  A  is  the  subject, 

"possesses"  is  the  relationship,  and 
"adv2mtage"  is  the  object.  (Figure  6) 


The  Air  Force  has  received  a  concept 
demonstration  of  the  DM.  It  executes  on  an 
Apple  Computer  Company  Macintosh  Computer . 
The  entire  demonstration  was  built  using  a 
hypertext  based  tool  called  SuperCard  by 
Silicon  Beach  Software  Inc .  The 
demonstration  illustrates  many  of  the 
concepts  discussed  in  this  paper.  At  this 
moment  a  prototype  of  the  DS  is  being  built 
by  Hughes  Aircraft  Company  for  the  United 
States  Air  Force .  The  prototype  is  being 
built  with  SuperCard. 


In  the  example  described,  the  DS  has 
been  programmed  to  know  what  relationships 
apply  to  the  node  called  Problem.  It  knows 
what  states  the  subject  Problem  contains . 
Furthermore,  it  is  aware  of  what 
relationships  pertain  to  the  object  called 
idea.  This  knowledge  is  expressed  as  rules 
and  is  stored  in  the  rule  base.  In 
conventional  expert  systems,  a  mechanism 
exists  for  invoking  a  rule  when  an  event 
occurs.  When  a  rule  is  invoked  a  condition 
is  tested  to  see  what  action  is  to  be 
performed.  One  action  causes  amother  rule 
to  be  Invoked.  A  situation  can  result 
where  a  chain  of  rules  is  invoked.  For  the 
DS,  a  large  chain  of  rule  invocations  is 
not  envisioned.  However  the  rule  base  may 
contain  a  large  number  of  rules  since  rules 
may  be  added  as  more  subjects  are 
encountered  in  the  development  effort . 

Without  the  rule  base  the  semantic 
network  is  not  useful . 

Rules  will  be  added  to  the  DS  by  the 
developer  or  by  another  individual  we  will 
refer  to  as  the  "System  Manager" .  The 
concept  calls  for  the  System  Manager  to 
create  the  initial  semantic  network  and 
adds  the  applicable  rules .  More  rules  can 
be  added  as  the  project  evolves  by  both  the 
System  Manager  or  by  the  individual 
developer  to  handle  the  needs  of  his 
perticular  development  role. 

The  DS  helps  in  the  collection  and 
organisation  of  the  knowledge  that  will  be 
useful  in  supporting  the  weapon  system. 

When  the  DM  is  transferred  to  the  support 
organization,  support  personnel  will  get  a 
view  of  the  system  from  the  developer' s 
perspective.  The  ideas  used,  adopted,  and 
'^fecarded  by  the  developer  for  solving 
problems  that  may  arise  again  during  PDSS, 
will  be  available  for  review  as  a  result  of 
the  DM.  Rational  for  the  development  of 
the  implementation  of  particular  algorithms 
will  be  accessible.  By  having  this 
information,  the  tisMi  spent  by  support 
personnel  for  Inforatation  search  and 
inference  will  be  reduced. 


SUMMARY 

Avionics  software  support  is  a  complex 
activity.  A  majority  of  the  time  spent  by 
personnel  in  maintaining  weapon  system 
software  involves  information  search  and 
reference.  The  Air  Force's  Wright 
Laboratory  is  performing  research  and 
development  to  reduce  the  eunount  of  time 
spent  upgrading  weapon  system  software. 

The  MECS  effort  is  focussing  on  this  area 
by  working  on  a  concept  called  DM.  The 
overall  goal  of  DM  and  its  DS  based  tool  is 
to  transfer  knowledge  from  the  developers 
to  the  support  personnel  in  the  form  of  an 
ISDP .  The  DM  involves  the  collection  and 
application  of  knowledge  and  therefore 
relies  on  a  knowledge  architecture  and  MI 
paradigm  that  uses  expert  system  concepts 
and  semantic  networks .  A  concept 
demonstration  has  been  completed,  while  a 
prototype  of  the  DS  is  now  under 
development . 
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Past  research  efforts yfn  the  field  of 
Command,  Control,  Communications,  and 
Intelligence  (C^I),j^ave  concentrated  on  the 
application  and  re^nement  of  advanced 
Artificial  Intelligence  (AI)  concepts. 
However,  the  man-machine  Interface  to  these 
advanced  applications  has  experienced  little 
improvement  and  does  not  adequately  reflect 
some  of  the  AI  concepts  embedded  within 
these  systems. 

The  development  of  more  advanced  computing 
techniques  requires  a  more  sophisticated 
Interface  to  the  system.  These  enhancements 
cannot  be  adequately  conceived  by  a  user 
using  traditional  display  techniques. 

This  paper  reveals  the  underlying  AI 
concepts  that  help  facilitate  the  transfer 
of  Information  between  acquired  C^I  data  and 
an  operator.  Many  of  these  concepts  are 
discussed  in  regard  to  their  application  in 
current  Tactical  Air  Force  research 
projects.  In  addition,  the  paper  discusses 
the  limitations  of  previous  program 
interfaces  and  the  current  advances  In 
graphical  interface  techniques,  v 


.  As  the  volume  of  data  that  an  operator  must 
analy2e  increases,  it  has  become  apparent 
that  better  techniques  are  required  for 
presenting  this  Influx  in  a  more  manageable 
manner. concepts  are  capable  of 
a  1  levlatirT^'sijuch  of  this  problem  through 
intelligent  malHRulat ions  of  the  data  and  by 
providing  recommenjfsrvigns  for  decision¬ 
making.  The  current  neeJf^efliong  Tactical  Air 
Force  operators  Is  for  Impro^T&i^..,^ 
visualization  of  the  spatial  relatl^^hlps, 
object  interdependencies,  decision 
reasoning,  modification  effects,  and  other^ 
alternatives  that  are  Incorporated  into  an 
AI  solution. 

The  graphical  enhancements  provided  in  this 
report  were  derived  from  the  Graphic  Systems 
Representation  (GSR)  study.  This  study  was 
initiated  in  June  1989  and  concluded  in 
March  1991  by  General  Electric  Company 
Research  and  Development  Center  for  Rome 
Laboratory.  The  scope  of  the  project  was  to 
develop  novel  graphical  techniques  for 
performing  Force  Level  Planning.  The 
results  of  this  study  are  Intended  to  be 
applied  to  future  planning  systems. 
Therefore,  some  of  the  graphical  techniques 
that  are  discussed  in  this  paper  are  not 
currently  implemented,  but  are  presented 
with  the  notion  that  they  may  be 
incorporated  into  future  systems. 

This  paper  focuses  on  two  decision  aid 
systems  that  incorporate  several  AI 
concepts,  the  Tactical  Expert  Mission 


PLAnneR  (TEMPLAR)  and  the  Identification  of 
Command  and  Control  Operations  Nodes  (ICON). 
TEMPLAR  is  a  frame-based  system  that  aids 
mission  planners  In  developing  an  Air 
Tasking  Order  (ATO) .  ICON  aids  intelligence 
analysts  in  tracking  enemy  movement  and  is 
based  on  a  blackboard  architecture  that 
provides  input  into  the  planning  process. 
This  paper  will  not  attempt  to  give  a 
complete  description  of  the  AI  encompassed 
in  ICON  or  TEMPLAR;  rather,  the  paper 
focuses  on  the  specific  implementation  of  a 
few  of  their  AI  concepts  to  show  how 
representative  graphical  output  can  enhance 
the  systems. 

The  following  two  sections  describe  TEMPLAR 
and  ICON,  respectively.  Within  each 
section,  a  background  of  the  system  is 
presented,  followed  by  a  discussion  of  a 
specific  domain  problem  in  each  of  the 
ensuing  main  subsections.  Each  domain 
problem  is  discussed  using  the  following 
format.  An  Introductory  section  describes 
one  of  the  domain  problems  incorporated  into 
the  system.  Then,  an  AI  description 
subsection  discusses  the  AI  concept  used  to 
solve  the  problem,  including  its  ability  to 
screen  and  process  data  for  recommended 
decisions  within  the  application.  Finally, 
a  graphical  enhancement  subsection  describes 
some  of  the  limitations  of  the  implemented 
display  techniques  and  proposes  some 
graphical  enhancements  to  better  represent 
the  AI  derivations. 


TEMPLAR  was  initiated  in  September  1985  and 
completed  in  October  1988  in  conjunction 
with  TRW.  It  is  designed  to  assist  the 
Ninth  Air  Force  in  ATO  planning,  in  areas 
where  essentially  no  comprehensive  system  of 
automation  existed.  A  more  thorough 
discussion  of  TEMPLAR'S  history  is  contained 
in  [51  . 

TEMPLAR  demonstrates  how  AI  concepts  can  be 
applied  to  the  Tactical  Air  Force  problem  of 
Air  Tasking  Order  (ATO)  generation.  An  ATO 
is  generated  by  Tactical  Air  Force  planners 
to  fight  tomorrow's  war.  The  plan  they 
produce  is  basically  a  schedule  that 
describes  the  force  level  use  of  aircraft 
and  their  associated  resources,  against  a 
list  of  nominated  targets  over  the  next  24 
hour  period. 

TEMPLAR  was  developed  using  Knowledge 
Craft®,  an  AI  language  tool-kit,  which  was 
developed  at  Carnegle-Mellon  University. 
Included  within  Knowledge  Craft®  are  problem 
solving  techniques  and  a  frame-based 
knowlsdge  representation  language  with 
procedural  attachments  and  inheritance. 
Knowledge  Craft®  assists  knowledge  engineers 
and  AI  system  builders  by  dramatically 
reducing  the  required  effort  in  building 
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knowledge-based  systems.  For  a  complete 
description  of  the  capabilities  of  Knowledge 
Craft^,  reference  [3]  and  [4] . 

A  requirement  of  TEMPLAR  was  to  support 
mixed  InltlatlT*  planning.  Mixed 
initiative  planning  Is  the  ability  to 
Interleave  planning  by  the  user  and  the 
system  (allowing  either  the  system  or  the 
user  to  plan  any  part  of  the  ATO) .  TEMPLAR 
Implements  mixed  Initiative  planning  by 
filling  out  forms.  This  implementation 
allows  the  user  to  fill  in  part  of  the  form 
without  affecting  the  planning  process. 

Every  field  on  a  form  in  TEMPLAR  is  tagged 
to  denote  if  it  is  user-owned  or 
autoplanner-owned.  Each  field  maps  to 
exactly  one  slot  in  one  frame  within 
Knowledge  Craft*^. 

TEMPLAR  contains  four  distinct  autoplanning 
modules.  Each  of  these  modules  generates 
mission  lines  (a  line  of  data  describing  the 
aircraft  configuration  for  a  mission) .  The 
paclcage  planner  generates  mission  lines  on 
the  Target  Planning  Worksheet  (one  of  many 
Implemented  forms) .  Of  the  four  modules, 
only  package  planning  will  be  discussed  in 
the  following  sections. 

_ Package  Planning 

Package  planning  is  the  process  of 
determining  the  aircraft,  the  time-over¬ 
target,  and  the  ordnance  (a  package),  that 
will  be  assigned  to  a  given  target.  A 
package  number  is  assigned  to  each  package 
for  easy  identification.  The  ability  to 
derive  an  efficient  and  satisfying  plan, 
that  encompasses  many  targets,  is  a  long  and 
tedious  process.  Since  an  infinite  amount 
of  resources  are  not  available,  cooperation 
and  coordination  among  available  resources 
become  key  elements  of  the  planning  process. 

The  planner  is  constrained  in  several  areas 
of  the  planning  process.  An  obvious 
constraint  to  the  planner  is  the  number, 
position,  and  abilities  of  the  aircraft  he 
has  available  to  complete  the  plan.  The 
planner  is  also  constrained  by  a  prioritized 


list  of  targets,  with  approximate  time-over- 
target  times  associated  with  each  target. 
Given  these  constraints,  along  with  weather 
and  other  unaccountable  logistical  problems, 
the  planning  process  becomes  increasingly 
complex . 

Figure  1  shows  a  TEMPLAR  worksheet 
containing  a  list  of  Offensive  Counter  Air 
(OCA)  targets  to  be  planned  (OCA  is  one  of 
many  mission  types  that  may  be  planned  with 
the  worksheet) .  This  worksheet  functions  as 
a  summary  of  the  OCA  packages  to  be  planned. 
Note  that  the  targets  are  associated  with  a 
package  number  and  an  estimated  time  over 
target  on  this  worksheet.  The  following 
paragraphs,  sutranarlze  a  sequence  of  events 
that  could  be  used  by  a  planner,  in  planning 
these  packages. 

A  planner  may  organize  the  development  of 
attack  packages  into  phases.  The  following 
phases  are  applied  to  each  of  the  Target 
Planning  Worksheets  the  planner  is  required 
to  plan;  estimate  the  aircraft  usage 
assuming  that  each  worksheet  receives  its 
first  weaponeering  choice  for  its  first  DMPI 
(Desired  Mean  Point  of  Impact),  determine 
the  set  of  weaponeerlng/tanker  combinations, 
calculate  the  order  for  examining  viable 
weaponeering  options,  and  determine  threats 
to  the  aircraft  en  route  to  the  nominated 
target . 

Upon  completion  of  these  initial  steps,  each 
worksheet  is  addressed  Individually  to 
determine  threat  dependencies.  The 
following  steps  are  applied  to  each 
worksheet:  attack  missions  are  planned;  a 
laser  designator  is  added;  if  required, 
force  protection  is  added;  if  required.  Wild 
Weasel  missions  are  added;  electronic  combat 
missions  are  scheduled,  if  required  and  Wild 
Weasel  support  is  not  possible;  if  fuel  is 
available  on  a  tanker  and  sorties  are 
available,  a  reconnaissance  mission  is 
scheduled.  A  more  complete  description  of 
the  package  planning  process  can  be  found  in 
(5).  TEMPLAR'S  implementation  of  the 
autoplanner  function  is  discussed  in  [6], 
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Figure  2  shows  a  target  planning  worksheet 
for  one  of  the  targets  listed  In  figure  1. 
The  previously  mentioned  steps  are  applied 
to  this  worksheet  to  determine  the  target's 
weaponeerlng  and  package  planning. 

Additional  menus  and  constraint  options 
assist  the  user  In  filling  In  the  fields. 

The  user  may  choose  the  MITOPUUI  selection 
to  task  TEMPLAR  to  automatically  fill  in  any 
blanks  on  the  worksheet. 

This  scenario  demonstrates  the  complexity 
Involved  with  package  planning.  It  becomes 
apparent  that  as  resources  become  more 
constrained,  and  the  number  of  targets 
increase,  the  difficulty  of  obtaining  an 
adequate  plan  Increases. 

3.1.1  Related  Schemata 

Within  Knowledge  Craft^,  frames  are 
referenced  as  schemata,  which  are  similar  to 
records  In  a  relational  database.  TEMPLAR 
uses  approximately  100,000  schemata  to 
Implement  its  many  functions.  Many  of  these 
schemata  are  related  to  each  other,  allowing 
TEMPLAR  to  integrate  a  variety  of  forms,  as 
Is  required  in  package  planning.  Each  schema 
(e.g.  objects,  situations,  concepts,  etc) 
has  a  name  and  a  set  of  slots  (e.g. 
attributes,  relationships,  and  methods) . 
Values  (e.g.  numbers,  symbols,  lists, 
schemata,  or  functions)  are  placed  within 
each  slot  to  store  relational  and 
attributive  information  about  an  entity. 

Schema  are  linked  (related)  to  each  other 
through  relations.  This  linkage  allows 
contents  from  one  schema  to  be  shared  by 
another  schema,  which  is  called  inheritance. 
By  setting  a  relation  to  a  schema,  only  the 
values  of  the  slots  defined  as  being 
"visible"  to  the  relation  can  be  Inherited. 
The  I8-A:  slot  Is  defined  by  Knowledge 
Craft*^  to  mean  that  all  characteristics  of 
the  ensuing  list  of  schemata  are  to  be 
Inherited.  Relations  may  also  be  defined  by 
the  Implementor  of  the  system.  Upon 
creating  the  slot's  name,  the  implementor 
defines  the  Inheritance  semantics  for  the 
relation  by  defining  the  required 


characteristics,  slots,  and  values  that  may 
be  Inherited  over  the  relation. 

Knowledge  Craft*'  allows  a  very  precise 
definition  of  Inheritance.  The  process  of 
defining  Inheritance  allows  values  to  be 
Included  or  excluded  from  being  inherited. 
The  mapping  of  operations  (converting  one 
value  to  another)  Is  also  possible  when 
defining  Inheritance.  Inheritance  can  be 
used  to  make  Inferences  by  allowing  the  user 
to  define  the  scope  (defines  nature  of 
related  schema)  and  transitivity  (defines 
nature  of  the  link)  of  the  relation.  These 
relations  are  used  to  control  the 
Information  flow  within  the  Knowledge  Base. 
Reference  [4]  contains  additional  detail  on 
using  schema. 

Figure  3  and  figure  4  are  sample  schemata. 
Figure  3  shows  the  deliver-house-materials 
activity.  Using  the  ZS-A:  slot,  deliver- 
house-materials  inherits  all  of  the 
characteristics  of  construction-activity  and 
delivery.  The  SOB-ACTIVZTZ-Or :  slot  is 
user-defined  to  Inherit  only  the 
COaSTRDCTZOli^ttSACnR:  specification  in 
the  build-house  schema  (figure  4). 

Therefore,  the  deliver-house-materials 
schema  has  Joe_Wllson  as  a  construction 
manager,  but  does  not  have  an  associated 
duration  time.  Build-house  operates  in  the 
same  fashion  as  deliver-house-materials, 
except  on  different  activities  and  with  a 
different  definition  for  the  SOB-ACTIVITY- 
OT:  slot. 

Package  planning  uses  inheritance  to  make 
Inferences  that  provide  the  user  with 
tailored  selections,  scheduling  resolutions, 
and  resource  availability.  The  planner  is 
able  to  step  through  the  required 
worksheets,  viewing  only  lists  of  feasible 
data  that  are  constrained  by  the 
environment.  Therefore,  scheduling 
unavailable  aircraft,  calculating 
Incompatible  weaponeerlng  options,  producing 
Insufficient  flight  distances,  and  many 
other  mistakes  are  not  possible. 
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3.1.2  TOT  Sliders 

It  is  essential  for  the  planner  to  keep 
track  of  many  interrelated  goals  and 
constraints  while  building  an  ATO.  However, 
these  relationships  (described  by  related 
schema)  are  blended  between  several  forms  in 
TEMPLAR.  To  the  user,  these  relationships 
become  vague  and  not  implicit;  consequently, 
while  attempting  to  formulate  a  large  plan, 
he  may  become  focused  on  an  individual 
section  of  the  plan  and  lose  the  "big" 
picture.  This  Imbalance  could  result  In  a 
less  efficient  plan.  This  problem  stems 
from  the  user  being  unable  to  view,  on  a 
single  screen,  a  package's  Interrelated 
sorties  (individual  aircraft)  and  temporal 
constraints.  A  graphical  technique,  known 
as  TOT  (Time-Over-Target)  sliders,  can 
provide  this  visualization  capability, 
allowing  the  planner  to  visualize  the 
geographic,  temporal,  and  resource 
properties  of  each  sortie. 

TOT  sliders  display  a  sortie's  mission 
window,  time-over-target,  flight  times,  and 
turn-around  time  (see  figure  5) .  The 
mission  window  is  shown  as  a  blue  horizontal 
line,  defining  an  axis  upon  which  the  rest 
of  the  components  of  a  TOT  slider  can  move. 
Time-over-target  is  displayed  as  a  green 
rectangular  box,  centered  over  the  mission 
window.  The  outgoing  and  returning  flight 
times  are  represented  as  dashed  blue 
horizontal  lines  attached,  respectively,  to 
the  top  and  bottom  of  the  time-over-target 
box.  The  turn-around  time  is  a  dashed  green 
line,  that  is  attached  to  the  end  of  the 
return  flight  time.  The  schedule  slippage 
sensitivity  (e.g.  a  long  flight,  penetration 
of  a  high  threat  zone,  scheduled  near  the 


end  of  the  mission  window)  of  the  sortie  is 
shown  by  the  amount  of  red  in  the  tlme-over- 
target  box. 

The  mission  window  is  taken  as  a  fixed 
entity,  upon  which  the  remaining  parts  of 
the  TOT  slider  (fixed  in  relation  to  each 
other)  may  slide.  As  the  planned  time-over¬ 
target  nears  the  end  of  the  mission  window, 
the  red  within  the  box  Increases.  The 
complete  TOT  slider  (except  the  mission 
window  line)  will  become  red  if  the  time- 
over-target  box  is  pushed  off  the  mission 
window  line  through  user  interaction 
("clicking  and  dragging"  on  the  TOT  slider) . 

In  multiple  sortie  packages,  constraints  may 
exist  between  two  or  more  sorties,  because  a 
temporal  relationship  exists  between  them 
(see  figure  6) .  TOT  sliders  may  be  defined 
as  predecessors  or  successors  of  each  other. 
Should  a  sortie  start  before  its  predecessor 
sortie  has  finished,  a  red  constraint 
violation  line  is  drawn  between  the  two 
time-over-target  boxes.  This  line 
disappears  when  the  TOT  sliders  are  moved  to 
avoid  the  constraint. 

In  figure  6,  the  top  sortie  is  a  predecessor 
to  the  bottom  sortie.  To  remove  the 
displayed  constraint,  the  sorties  must  be 
moved  apart  by  the  distance  of  the 
constraint  line.  Once  the  sorties  are  moved 
sufficiently  apart,  the  constraint  line  is 
erased. 

The  final  constraint  that  is  associated  with 
the  TOT  slider  is  a  limited  resource 
constraint  (see  figure  7).  The  bottom  of 
the  display  shows  a  simple  plot  of  the 
resources  available  to  the  planner.  The 
plot  reflects  the  amount  of  resources  left 
for  allocation  at  any  one  time.  As  the  TOT 
sliders  are  moved  around,  the  plot  is 
updated  to  show  the  changes  in  resource 
levels.  The  plot  is  drawn  in  black  when 
there  is  a  positive  amount  of  resources 
available,  and  in  red  when  the  resource 
becomes  over  committed.  Reference  [1) 
contains  a  more  detailed  description  of 
mission  scheduling  with  TOT  sliders. 

TOT  sliders  are  extremely  flexible  in  the 
visualization  of  time,  resource,  and 
spatially-constrained  problems.  Many 
interrelated  sorties  and  packages  may  be 
displayed  with  several  resource  plots,  to 
give  the  planner  the  "big"  picture.  The 
ability  to  visualize  a  plan  can  greatly 
enhance  the  planner's  capability  to  produce 
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a  successful  plan. 

_ Resource  Allocation 

Resource  allocation  Is  an  Integral  part  of 
the  package  planning  process,  because  it 
determines  what  resource  will  be  used  to 
satisfy  a  need.  This  process  Is  much  like  a 
bookkeeping  process  -  resources  are  recorded 
and  tracked  according  to  their  availability. 

Resource  allocation  occurs  at  many  levels  of 
the  planning  process.  Tanker  tracks, 
weapons,  sorties,  and  time  are  among  some  of 
the  resources  that  must  be  allocated.  As 
these  resources  become  constrained,  the 
ability  to  develop  a  comprehensive  package 
becomes  more  complex.  Some  of  the 
difficulty  In  seeing  a  complete  picture  is 
visible  between  figure  1,  containing  the 
list  of  all  the  OCA  targets,  and  figure  2, 
representing  part  of  the  planning  for  a 
target. 

In  the  process  of  developing  an  ATO, 
resource  allocation  can  be  viewed  as  a 
complex  network  of  checks  and  balanceo. 
Affecting  one  resource  in  a  part  of  the 
planning  cycle  could  have  a  dramatic  effect 
on  another  part  of  the  plan.  Therefore, 
resource  allocation  is  not  a  simple  process, 
but  rather  a  series  of  small  checks 
throughout  the  planning  cycle. 

_ Constrained  Schemata  and  Demons 

Demon  Information  on  a  slot  Is  a.iother 
method  for  the  slot-control  schema.  A  demon 
Is  a  function  that  Is  associated  with  a 
particular  slot  in  a  schema.  When  the  slot 
Is  updated  (beyond  a  given  set  of 
conditions),  the  demon  Is  executed. 
Therefore,  demons  provide  a  reactive  action, 
executed  under  specific  circumstances  In  the 
systems  knowledge. 

Within  TEMPLAR,  demons  perform  quality 
control  functions  during  the  development  of 
an  ATO.  Demons  are  primarily  used  In 
resource  tracking,  calculating  mission 
length,  and  unit  scheduling.  The  allocation 
of  aircraft  to  missions  Is  also  maintained 
by  demons  in  TEMPLAR.  Demons  are 
responsible  for  controlling  the  Internal 
records  of  the  allocations  and  notifying  the 
user  If  a  particular  subunit  becomes  over 
tasked.  Reference  [51  for  a  more  complete 
listing  of  the  automatic  checking 
Incorporated  Into  TEMPLAR. 


Demons  within  Knowledge  Craft®  provide 
procedural  attacliment  by  being  associated 
with  Lisp  functions.  If  a  slot  contains  a 
demon,  access  to  that  slot  causes  the  demon 
to  "fire"  •  (execute)  and  recalculate  the 
value  of  each  activity  associated  with  It. 
Multiple  demons  may  be  associated  with  one 
slot  to  aid  In  maintaining  internal 
consistency  of  the  Knowledge  Base.  De.mons 
are  defined  by  describing  the  conditions  on 
which  It  will  "fire,"  the  effect  it  will 
have  on  the  value.  If  it  will  "fire"  before 
or  after  the  last  command,  and  the  action  it 
will  take  upon  "firing."  Reference  [4]  for 
more  Information  on  defining  demons. 

Within  TEMPLAR,  demons  are  used  to  control 
the  updating  of  related  fields.  They  are 
assigned  to  monitor  a  field,  wait  until  it 
Is  updated,  then  calculate  and  update  other 
related  fields.  The  demons  actions  within 
TEMPLAR  are  not  shown  explicitly  to  the 
user,  however,  the  actions  described  in  the 
allocation  of  aircraft  (above)  could  be 
displayed  as  described  In  the  following 
section . 

3.2.2 _ Resource  Allocation  Networks 

Resource  allocation  networks  focus  on  the 
allocation  of  aircraft  to  targets  (see 
figure  8) .  The  network  of  resource  and 
target  icons  provide  a  convenient 
visualization  of  the  allocation  of  resources 
to  targets,  and  alternative  uses  for  each 
resource.  Using  this  visualization 
technique,  the  user  becomes  mere  aware  of 
his  constraints  and  options. 

On  the  network,  time  flows  from  the  left  to 
the  right.  A  green  octagonal  Icon  and  a 
stack  of  boxes  to  its  right  represents  the 
resource,  with  a  label  for  the  resource 
type,  location,  and  unused  quantity.  Targets 
are  represented  In  red  boxes,  with  two 
meters  on  either  side  and  a  stack  of  boxes 
on  the  far  left.  Each  box,  within  the  stack 
of  boxes,  may  be  tagged  with  a  green  dot,  to 
Indicate  a  type  of  aircraft  that  may  be  used 
against  the  target.  The  orange  meter  to  the 
left  of  the  target  shows  the  kill 
probability  and  the  meter  to  the  right  of 
the  target  shows  the  value  of  the  target. 

Targets  and  resources  are  connected  by  a 
blue  line  between  a  box  In  each  of  the 
Icon's  stack  of  boxes.  The  box  that  Is 
connected  on  the  resource  side  contains  the 
number  of  resources  that  are  allocated  to 
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that  target.  Since  time  flows  from  the  left 
to  the  right,  the  horizontal  distance  of  the 
connecting  line  Indicates  the  duration  of 
the  mission.  A  resource  that  may  be  reused 
after  a  mission  can  be  shown  to  the  far 
right  of  the  target  Icon  by  a  box  with  the 
number  of  resources  In  It.  This  box  may  then 
be  treated  as  a  normal  resource  box.  An 
excellent  description  on  the  uses  of  the 
resource  allocation  networks  may  be  found  In 
[11  . 

Figure  8  shows  a  sample  allocation  of 
resources  from  two  bases  being  used  against 
three  targets.  By  the  positioning  of  the 
three  targets,  It  Is  clear  that  Target2  will 
be  the  first  target  attacked,  followed  by 
Targetl  and  Target!,  respectively.  The 
connecting  lines  show  that  three  resources 
are  designated  to  Targetl  and  Target2  from 
the  first  base,  and  two  resources  to  Target2 
and  three  resources  to  Target!  from  the 
second  base.  The  meters  on  each  side  of  the 
target  Icons  show  the  kill  probability  and 
the  value  of  each  target. 

The  natural  language  capabilities  of  TEMPLAR 
tell  the  planner  If  a  resource  Is  available 
using  numiiers  and  text.  However,  numbers 
are  difficult  to  work  with,  and  text  from  a 
natural  language  Interface  (e.g.  large, 
small,  no,  ok)  may  be  ambiguous.  Risk  and 
reward  meters  may  be  associated  with  every 
connecting  line  within  the  resource 
allocation  network  <see  figure  9) .  These 
meters  can  display  the  risk  of  losing  the 
aircraft,  the  reward  of  using  an  aircraft, 
and  aircraft  range  limitations.  These 
meters  may  also  reflect  the  effect  of  the 
current/predicted  weather  for  the  mission. 

Resource  allocation  networks  allow  the 
visualization  of  time,  resource,  and 
spatially  constrained  problems  (e.g.  target 
based).  These  networks  also  utilize  bar 
charts  for  easy  comparison  and  sensitivity 
checks.  These  graphical  portrayals  allow 
the  user  to  understand  the  resource 
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allocation  situation  at  a  glance  and 
visualize  the  risks  and  rewards  associated 
with  many  feasible  resource  allocation 
alternatives.  This  type  of  synergism  Is  not 
possible  with  a  purely  text-based  Interface 
that  requires  the  user  to  read  all  of  the 
details . 

A. _ ICON  BACKGROUND 

The  ICON  decision  aid  was  initiated  In  July 
1987  and  completed  In  December  1989  in 
conjunction  with  PAR  Government  Systems. 

ICON  is  a  field-demonstrable  advanced- 
development  prototype.  ICON  aids  the 
intelligence  analysts  of  the  Tactical  Air 
Control  Center  (TACC)  Combat  Intelligence 
Division  (CID)  in  the  development  and 
maintenance  of  the  Command,  Control,  and 
Communications  Order  of  Battle  (C^OB) .  The 
ultimate  goal  of  ICON  is  to  provide 
assistance  that  will  enable  more  timely  and 
accurate  inputs  to  battle  planning,  and 
result  In  a  more  responsive  ATO.  Reference 
[21  presents  a  more  complete  history  of 
ICON. 

ICON  was  developed  using  an  object-oriented 
approach  for  the  design  and  Implementation 
of  the  software.  The  knowledge 
representation  provides  a  natural  and 
flexible  way  to  model  knowledge  about  enemy 
units  and  C^  structure.  The  system  relies 
on  a  blackboard  architecture,  an  object- 
oriented  knowledge  representation,  and 
probabilistic  rule-based  Inference 
mechanisms.  Figure  10  shows  the  software 
architecture  Implemented  in  ICON. 

The  blackboard  architecture  provides  the 
means  for  bringing  diverse  problem-solving 
techniques  to  bear  on  the  problem.  The 
blackboard  contributes  to  the  ability  of  the 
system  to  handle  the  piecemeal  stream  of 
data  that  must  be  analyzed.  The  data 
required  for  analysis  Is  taken  from  Entity 
Data  Records  (EDRs),  which  are  Intelligence 
reports  from  the  field.  A  probabilistic 
rule-based  Inference  mechanism  provides  a 
way  of  handling  the  uncertainty  associated 
with  data  that  may  be  sparse  and  of  varying 
degrees  of  confidence. 


27-7 


Figure  10:  ICON  Sortware  Architecture 


4.1  Determining  Threats  from  EDR  Messages 

Analysis  of  the  incoming  EDR  messages  is 
part  of  the  Command,  Control,  and 
Communications  Countermeasures  analysis 
function  within  the  TACC.  These  analyzers 
receive  intelligence  information  and  ate 
tasked  with  determining  the  positions  of  the 
threats.  Much  of  the  information  that  is 
received  by  the  analysts  is  vague  and 
seemingly  unrelated.  The  more  deceitful  an 
enemy  is  and  the  fewer  capabilities  you  have 
for  collecting  intelligence,  the  more  vague 
and  irrelevant  the  Information  will  appear. 
Analysts  are  also  overwhelmed  at  times  with 
bits  and  pieces  of  information  that  cannot 
be  correlated  and  cross-referenced  In  a 
timely  manner. 

The  Increased  use  of  mobile  threats  creates 
an  even  more  complex  situation  for  the 
analyst.  As  the  threats  move,  the  analyst 
must  be  able  to  determine  if  two  different 
reports  on  the  same  type  of  signal  are 
actually  different  threats,  or  the  same 
threat  that  is  moving.  Many  threats  are 
capable  of  broadcasting  in  several  different 
frequencies.  This  ability  requires  the 
analysts  to  retain  the  knowledge  of  the 
frequencies  that  different  types  of  threats 
are  capable  of  broadcasting. 

EDR  messages  provide  an  immense  amount  of 
information.  However,  valuable  information 
is  often  hidden  among  several  EDR  messages, 
or  not  readily  apparent.  The  ability  to 
plan  an  effective  ATO  may  result  in  a 
planner's  capability  to  decipher  the 
Information  contained  within  the  EDR 
messages.  The  following  section  describes 
the  blackboard  architecture  that  Is  used  to 
capture  and  correlate  all  of  the  data 
contained  in  the  EDR  messages. 


li.l  .1 _ Blackboard 

The  ability  to  determine  a  threat  from  EDR 
messages  requires  a  system  that  is  capable 
of  handling  fragments  of  data.  A  blackboard 
system  is  implemented  to  allow  for  the 
ability  to  generate  incremental  solutions. 
The  system  Incorporates,  in  a  central  data 
structure,  a  model  of  problem  solving  as 
defined  by  the  problem  domain.  A  group  of 
independent  experts,  called  "knowledge 
sources”  (reference  section  4.2.1),  are 
allowed  to  manipulate  this  domain.  Through 
Incremental  manipulations  of  the  domain,  a 
solution  to  a  problem  is  generated.  The 
blackboard  is  shown  as  part  of  the  software 
architecture  (labeled  Obj*ct  Znstancwa)  in 
figure  10. 

The  design  of  the  blackboard  is  based  on  an 
event-driven  class  hierarchy,  where  an  event 
is  a  recorded  change  to  the  blackboard. 

These  classes  are  used  to  define  the 
blackboard's  system  functionality.  The 
Event  List  classes  contain  and  coordinate 
the  processing  of  the  event  class  instances. 
Event  processing  is  tasked  with  finding 
knowledge  source  objects  which  are 
"triggered"  by  an  event.  For  each 
"triggered"  knowledge  source  that  is 
discovered,  the  blackboard  is  asked  to  add 
an  activity  object  (created  from  the 
activity  class  that  describes  "triggered" 
knowledge  sources)  to  itself. 

The  ICON  blackboard  provides  a 
representation  of  the  Identified  and 
hypothesized  enemy  units  and  their 
relationships.  In  other  words,  at  any  given 
moment  the  information  encapsulated  on  the 
blackboard  represents  a  partial  solution  to 
the  c2  node  identification  problem.  The 
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blackboard  also  tracks  evidential 
relationships  between  pieces  of  Information 
(derived  from  the  analysis  of  the  EDR  data) 
on  various  levels.  Reference  [2]  for  more 
Information  on  the  ICON  blackboard  system 
and  the  BBTHING  framework  used  to  develop 
the  ICON  blackboard. 

The  stages  In  the  process  of  analyzing  EDR 
data  are  represented  In  the  ICON  blackboard 
by  four  levels:  Data,  Emissions,  Emitters, 
and  Nodes/Networks.  EDR  records  are  added 
to  the  system  at  the  lowest  level,  the  Data 
level.  Emissions  are  Identified  on  the 
Emissions  level,  being  derived  from  multiple 
or  single  data  records  on  the  Data  level. 
Emissions  are  signals  that  have  been 
detected  over  a  period  of  time  at  a  specific 
location.  Equipment  that  causes  the 
emissions  can  be  identified  on  the  Emitters 
level.  The  Emitters  level  represents 
Individual  pieces  of  equipment,  which  were 
derived  from  a  series  of  emissions  over  a 
period  of  up  to  a  few  hours.  The  highest 
level  In  the  blackboard  contains  c2  Nodes, 
that  are  Identified  by  groups  of  emitters. 
c2  network  organization  is  Indicated  by 
Identifying  c2  relationships  from  a  pattern 
of  emissions  from  particular  emitters. 

These  networks  ate  represented  on  the  top 
level  as  links  between  objects. 

Objects  represent  data  and  enemy  emissions, 
equipment,  and  units.  Each  object  belongs 
to  a  class,  and  each  class  of  objects 
belongs  to  only  one  level  of  the  ICON 
blackboard.  At  the  lowest  level,  the  data 
objects  represent  the  EDR  records  (Input 
into  the  ICON  system) .  The  data  is 
propagated  through  the  remaining  levels  of 
the  blackboard  by  the  "firing*  of  knowledge 
sources.  The  knowledge  sources 
Independently  analyze  the  data,  deriving 
updated  Information  for  the  blackboard.  For 
more  Information  on  the  knowledge  sources 
reference  section  4.2.1. 

4.1«2 _ Situation  Maps 

As  data  Is  propagated  through  the 
blackboard,  the  user  Is  unaware  of  Its 
existence  until  It  reaches  the  top  level. 

Due  to  the  vagueness  of  some  types  of  EDR 
messages,  it  may  take  long  periods  of  time 
before  enough  Information  is  gathered  to 
make  a  positive  Identification.  Giving  the 
analyst  Information  on  this  vague  knowledge 
could  help  them  In  determining  possible 
future  threats. 

A  situation  map  portrays  data  In  a  three- 
dimensional  surface  that  encompasses 
geographic  and  temporal  variations. 

Situation  maps  allow  Incomplete  data  to  be 
plotted  on  a  map  background  (see  figure  11). 
All  of  the  data  represented  in  the 
blackboard  has  a  degree  of  uncertainty 
associated  with  its  accuracy;  for  example. 


the  data  contains  a  latitude/longitude 
reference  point  (some  degree  of  unknown) . 
Using  the  X  and  Y  values  of  the 
latitude/longitude  area,  and  a  Z  value  of 
certainty,  the  data  may  be  plotted  as  a 
three-dimensional  surface.  Varying  color 
patterns  may  be  added  to  depict  other 
relevant  attributes.  This  type  of  map  would 
be  continuously  evolving  as  new  data  is 
received  and  updates  are  made  to  the 
blackboard  system. 

Figure  11  shows  a  threat  situation  over  part 
of  a  grid.  Note  that  no  terrain  is  mapped 
onto  this  map.  The  situation  map  reflects 
the  threat  Intensity  throughout  the  grid 
block  by  the  height  of  the  "hills."  The 
left  side  shows  a  small  ridge  of  "hills," 
Indicating  low  level  threat  reporting.  The 
right  side  shows  a  larger  ridge  of  "hills," 
Indicating  a  higher  level  threat.  "Valleys" 
are  signs  of  threats  not  being  detected  or 
not  existing  at  a  particular 
latitude/longitude.  Currently,  no  icons 
have  appeared  on  the  map.  This  implies  that 
the  sum  of  the  reporting  are  currently  not 
conclusive  enough  to  be  labeled. 

The  situation  map  represents  the  current 
Information  held  within  the  blackboard.  When 
messages  reach  the  top  level  of  the 
blackboard  they  become  identified,  and  the 
situation  map  Is  replaced  by  the  target's 
Icon.  Likewise,  if  data  becomes  too  old  and 
Is  discarded  from  the  blackboard,  that  part 
of  a  situation  map  would  be  removed.  These 
animated  situation  maps  would  contain  the 
most  current  unidentified  Intelligence  data. 

Situation  maps  provide  an  analyst  with 
Insight  to  probable  enemy  activity.  From 
these  maps,  the  analyst  can  watch  future 
activity  develop.  This  ability  can  aid  the 
analyst  In  determining  trends  in  enemy 
activity.  Situation  maps  may  also  be 
applied  In  other  areas  where  the  Interaction 
between  multiple  related  values  need  to  be 
visualized.  Reference  [1]  for  a  complete 
explanation  on  the  uses  of  situation  maps 
and  their  application  to  Force  Level 
Planning. 

_ Information  about  Identified  Targets 

Currently  the  CID  Intelligence  Analysts  have 
little  automation  to  help  them  in  analyzing 
EDR  files.  EDR  files  arrive  at  the  post 
where  they  are  read  and  interpreted  by  the 
analysts.  ICON  provides  an  automated  way  to 
process  the  EDR  files,  allowing  the  analysts 
to  spend  more  time  analyzing  the  data. 

Once  ICON  identifies  a  target,  the  analysts 
require  a  natural  and  explicit  method  for 
analyzing  the  data.  ICON  provides  these 
methods  by  plotting  the  targets  on  a  map  and 
allowing  the  user  access  to  the  rationale 
(EDR  messages)  used  to  identify  the  target. 

The  following  sections  discuss  how  ICON'S 
use  of  backward  chaining.  Icons,  and 
spreadsheets  enable  the  user  to  retrieve 
Information  about  the  Identified  targets. 
This  part  of  ICON  captures  the  essence  of 
incorporating  graphics  and  text. 

4-2.1 _ Backward  Chaining 

ICON  uses  a  blackboard  (reference  4.1.1)  to 
aid  in  the  identification  of  targets  through 
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Figure  12:  Sample  ICON  Display 

piecemeal  data.  A  trail  (log  of  update 
messages)  Is  kept  on  the  EDR  data  as  It  Is 
propagated  through  ICON'S  blackboard, 
allowing  ICON  to  track  the  flow  of  data. 


derived  from  the  EDR  messages  and  Is 
contained  within  the  blackboard  to  suggest 
that  a  particular  enemy  asset  exists  at  a 
particular  latitude/longitude. 


When  additional  Information  on  the 
Identification  of  a  particular  target  Is 
requested,  backward  chaining  takes  place  on 
the  trail.  By  revealing  the  trail  that 
obtained  the  answer,  the  user  Is  made  aware 
of  the  process  made  In  Identifying  the 
target.  Figure  12  shows  the  rationale 
window  (displays  the  trail)  for  a  Command 
Post  In  the  bottom  left  corner.  The  trail 
Is  formed  by  the  successful  "firings"  of  the 
knowledge  sources  on  data  In  the  blackboard. 

The  knowledge  sources  that  use  the  Embedded 
Rule-based  System  (ERS)  are  derived  from  a 
common  base  class  (ERS  KS),  that  Is  derived 
from  the  class  provided  by  the  blackboard 
system  (for  more  Information  on  ERS 
reference  section  4.3.1).  These  knowledge 
sources  are  associated  with  a  rule  base  and 
a  set  of  functions  for  gathering  evidence 
from  the  blackboard  and  performing  actions 
to  update  the  blackboard.  Figure  10  labels 
these  knowledge  sources  as  XS-1  ..  KS-n. 
These  knowledge  sources  represent  a  group  of 
Independent  experts  that  can  generate  a 
solution  to  a  problem  by  manipulating  data 
within  the  blackboard.  Reference  (21 
contains  a  complete  description  on  the 
knowledge  source  Implementation. 

Creating  a  new  object  at  the  highest  level 
of  the  blackboard  results  In  the  plotting  of 
a  new  Icon.  This  icon  is  displayed  at  the 
approximate  latitude/longitude  of  the  threat 
as  Indicated  in  the  EDR  messages.  The  Icon 
represents  that  conclusive  evidence  has  been 


4.2.2  Icons  and  Spreadsheets 

ICON  uses  graphic  Icons  to  portray  units  of 
enemy  assets.  These  assets  are  plotted  at 
their  approximate  location,  on  a  two 
dimensional  map  of  the  terrain.  ICON  also 
provides  labeled  cities,  a  coordinate  grid, 
a  Forward  Edge  of  the  Battle  Area  (FEBA) , 
and  a  Fire  Support  Coordination  Line  (FSCL) , 
to  help  orientate  the  analyst  on  the 
battlefield.  The  map  portion  of  figure  12 
shows  only  some  known  units  and  the 
coordinate  grid. 

ICON  uses  simple  icons  that  intuitively 
remind  the  user  of  the  object  it  represents, 
with  varying  Icon  colors  to  Indicate  an 
icon's  current  status.  Enemy  units, 
portrayed  as  a  single  icon  on  the  map, 
represent  many  vehicles  and  equipment  that 
are  associated  with  a  particular  unit.  Due 
to  the  size  of  the  display,  ICON  is  not  able 
to  plot  each  member  of  the  unit  and  provide 
an  uncluttered  view  of  the  battlefield. 
Therefore,  ICON  provides  an  alternative 
method  for  retrieving  more  information  about 
a  particular  unit. 

To  reveal  more  Information  about  the 
displayed  assets,  the  user  "clicks"  (with  a 
mouse)  on  an  Icon.  Backward  chaining 
(described  In  section  4.2.1)  is  performed  on 
the  icon's  blackboard  representation  to 
reveal  the  Identified  pieces  of  equipment 
known  to  compose  the  unit.  This  information 
Is  displayed  In  a  tree  format  In  a  separate 
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display  window  (lower  right  window  In  figure 
12)  . 

The  tree  format  shows  the  unit  Icon  at  the 
top,  with  each  of  the  known  assets  within 
the  unit  linked  underneath  It.  Many 
analysts,  aside  from  knowing  the  available 
assets  that  are  associated  with  a  unit,  also 
want  to  know  how  the  associated  assets 
became  known.  The  past  messages  used  to 
determine  an  enemy  asset  may  be  accessed 
through  the  rationale  window. 

To  determine  the  rationale  (EDR  messages 
used  to  Identify  an  object),  the  user 
"clicks"  (with  a  mouse)  on  a  limb  of  the 
tree.  The  backwards  chaining  process 
(described  In  section  4.2.1)  Is  Invoked  on 
the  blackboard's  representation  of  the  link 
to  reveal  the  evidence  supporting  the 
components  Identification.  This  evidence  Is 
presented  In  text  format  In  a  separate 
window.  The  bottom  portion  of  figure  12 
shows  the  tree  window,  with  the  rationale 
window  on  Its  left. 

ICON  demonstrates  a  good  blend  of  textual 
spreadsheets  and  graphic  Icons.  ICON  shows 
that  the  use  of  graphics  can  be  used  to 
enhance  a  text-based  system  and  still  allow 
the  user  access  to  text  or  exact  numbers 
when  needed.  It  does  not  limit  a  user  to  a 
graphic  Icon  or  require  an  extensive  search 
to  find  the  exact  data. 

i-iJ _ large!.  Analysis  over  Time 

Part  of  an  analyst's  job  is  predicting 
future  enemy  activity.  By  comparing  current 
trends  in  threat  movements  against  Itnown 
doctrine  or  past  performances,  a  correlation 
may  (help)  determine  the  future  moves  of  the 
threats.  The  ability  to  notice  these  trends 
early  in  the  discovery  of  a  threat  may 
provide  additional  Insight  to  an  enemy's 
goals . 

Upon  noticing  trends,  the  analyst  may 
determine  the  predicted  path  of  the  enemy 
and  possibly  some  of  his  targets.  By 
obtaining  this  knowledge,  effective 
countermeasures  can  be  prescribed.  This 
information  may  show  a  vulnerable  area  in 
the  friendly  force  defenses  or  reveal  a 
valued  enemy  resource  or  target.  Although 
friendly  forces  are  not  shown  in  ICON,  this 
capability  could  be  added  In  the  future. 

The  ability  to  compare  past  and  current 
trends  in  enemy  force  deployment  can  be 
extremely  helpful  to  an  analyst.  However, 
acquiring  the  past  data  and  drawing 
conclusions  based  upon  the  data  Is  complex. 

i.3.1 - Inference  Mechanism 

When  a  knowledge  source  Is  "triggered, "  ERS 
is  notified  to  execute  the  associated  rule 
base.  The  knowledge  source  then  provides 
the  Information  from  the  blackboard  to  the 
executing  rule  base.  The  rule  base  action 
functions  process  and  return  updates  to  the 
knowledge  source.  Upon  receiving  the 
updates  from  ERS,  the  knowledge  source 
performs  analytical  updates  to  the 
blackboard.  Figure  10  shows  the 
communication  between  ERS  and  the  rule 
bases,  and  ERS  and  the  knowledge  sources. 


ERS  represents  the  collection  of  rules 
(links)  that  form  a  rule  base  as  an 
Inference  network.  Within  this  network, 
nodes  represent  antecedent  conditions  and 
consequent  statements  with  an  associated 
degree  of  belief  (value  reflecting  the 
Importance  of  the  antecedent  condition  and 
consequent  statements) .  Links  represent 
rules  which  may  have  an  associated  additive 
weight  of  evidence. 

Two  types  of  nodes  are  used  In  the  Inference 
network,  leaf  and  goal  nodes.  A  leaf  node 
represents  evidence  provided  from  the 
blackboard  or  model  data  structure.  A  goal 
node  that  Is  not  an  antecedent  condition  for 
any  rule  represents  conclusions  whose 
certainty  is  to  be  determined  by  the  rule 
base.  A  goal  node  Is  usually  associated 
with  an  action  function  that  performs  some 
change  to  the  blackboard. 

The  rule  base  may  execute  one  or  more  action 
functions  when  a  single  knowledge  source  is 
"triggered."  The  action  functions  that  are 
executed  depend  upon  the  evidence  collected, 
the  certainty  of  evidence  (value  assigned  to 
goal  nodes  by  the  rules  as  a  function  of  the 
amount  of  evidence) ,  and  the  strategy  for 
action  function  execution  specified  for  the 
rule  base.  An  Ir.-depth  discussion  on  the 
rule  base  may  be  found  in  [2]. 

Although  not  currently  Implemented,  the 
rule-based  Inferenclnq  available  In  ERS 
could  be  used  to  determine  objectives  and 
Intent  of  threats  by  filling  it  with  the 
threats  doctrine. 

4.3.2 _ Coordlnat>^d  .Mission  Maos 

ICON  does  not  animate  the  icons  on  its 
display.  Once  a  threat  is  detected  and  put 
on  the  screen  it  will  remain  there  until  the 
analyst  determines  the  data  is  too  old.  ICON 
treats  the  data  as  a  time-tagged  snapshot  of 
the  world.  However,  by  adding  some 
Intelligence  about  the  decay  rate  of 
Information  and  the  tactics  of  the  enemy, 
ICON  could  animate  its  data. 

Adding  intelligence  about  the  decay  rate  of 
Information  would  allow  ICON  to  remove  old 
data.  As  the  Information  concerning  a 
specific  threat  becomes  old  (no  new 
Information  to  backup  the  old  Information), 
the  confidence  level  (a  value  that 
represents  the  degree  of  belief  that  an 
object  exists)  In  the  threat  would  subside. 
As  the  confidence  level  begins  to  decay,  the 
icon  would  turn  back  into  a  situation  map 
(described  In  section  4.1.2)  and  may 
eventually  disappear. 

Adding  enemy  tactics  (possibly  within  the 
Inference  mechanism  described  In  section 
4.3.1)  would  allow  ICON  to  animate  the 
projected  moves  of  the  enemy.  The  Icons 
displayed  on  the  grid  portion  of  figure  12 
represent  the  Icons  that  could  be  animated. 
ICON  could  track  the  enemies  known  positions 
and  play  them  back  to  the  analyst.  From 
these  movements  and  the  knowledge  of  enemy 
tactics,  ICON  could  begin  to  animate 
projected  moves.  This  capability  could 
greatly  enhance  the  analyst's  ability  to 
recognize  key  coordination  points  In  the 
enemy's  attack,  intentions,  and  objectives. 
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Applying  spatial  and  temporal  coordination 
constraints  on  the  data  being  tracked  can 
reveal  other  threats  that  may  exist,  but 
have  not  been  found.  Refueling,  supply 
lines,  and  weapon  depots  are  a  few  items 
that  could  be  found  by  animating  and 
observing  the  threat  activity.  The  time- 
stepped  animation  of  events  may  also  allow 
the  slack  times  and  critical  rendezvous'  of 
the  enemy's  plan  to  be  seen.  Reference  [1] 
for  a  complete  description  of  coordinated 
mission  maps  and  their  application  to  Force 
Level  Planning  animation. 

^ — CQNCLUSIflJtlS 

Applying  the  graphical  enhancement 
techniques  derived  In  the  GSR  study  to  ICON 
and  TEMPLAR  proved  to  be  a  worthwhile  task. 
The  process  of  applying  these  techniques 
revealed  that  some  of  the  enhancements 
already  existed  (ICON'S  use  of  icons  and 
spreadsheets) ,  other  enhancements  could  be 
used  directly  from  the  study  (TEMPLAR'S  use 
of  TOT  sliders  and  resource  allocation 
networks),  and  a  few  of  the  enhancements 
required  tailoring  to  the  problem  domain 
(ICON'S  use  of  situation  maps  and 
coordinated  mission  maps) .  Therefore,  the 
task  demonstrated  that  the  graphical 
enhancements  derived  in  the  study  could  be 
applied  to  existing  AI  applications. 

This  task  also  provided  Insight  into  the 
amount  of  information  that  Is  captured 
within  the  AI  concepts,  but  not  shown  to  the 
user  (possibly  due  to  time  and  processing 
constraints).  TEMPLAR'S  related  schemata 
and  ICON'S  blackboard  are  two  examples  of 
information  captured  but  not  displayed.  The 
relationships  between  TEMPLAR'S  schemata  are 
spread  across  several  worksheets  (making  the 
relationships  very  difficult  to  detect)  and 
ICON  only  displays  data  (objects)  on  the  top 
level  of  the  blackboard  (not  allowing  the 
user  to  see  other  information  contained 
within  the  blackboard) .  The  graphical 
enhancements  discussed  on  each  of  these 
concepts  would  allow  this  data  to  be  shown 
clearly  to  the  user. 

Each  application  has  Its  own  requirements 
for  textual  and  graphical  data.  Graphics 
should  be  used  to  help  the  user  of  the 
system,  and  not  over-used  to  the  point  of 
causing  more  confusion.  One  way  to  avoid 
adding  confusion  to  a  system  Is  to  expose 
the  user  to  the  enhancements  as  part  of  an 
iterative  cycle:  analysis  of  the  system, 
implementation  of  enhancements,  obtain  user 
feedback,  apply  feedback  to  analysis  of  the 
system.  In  this  context,  this  paper  has 
only  addressed  the  analysis  phase  In  the 
iterative  cycle. 

Users  must  be  made  aware  of  the  enhancements 
that  can  be  provided  to  them  by  combining 
graphics  and  AI  concepts  Into  their  current 
methodologies.  Implementing  a  system  that 
strictly  mirrors  a  nonautomated  methodology 
may  not  be  using  the  computer  to  its  maximum 
potential.  By  composing  an  appropriate 
blend  of  AI  and  graphics,  much  of  the  Influx 
of  data  currently  felt  by  the  user  may  be 
avoided.  However,  an  absence  of  this 
blending  could  result  In  unfriendly, 
inefficient,  or  misleading  systems. 

This  paper  has  attempted  to  demonstrate  the 
need  for  synergism  between  AI  concepts  and 


representative  graphical  output.  By 
focusing  on  a  few  examples.  It  is  the  intent 
of  the  paper  to  convey  the  overall 
usefulness  of  this  synergism. 
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SUMMARY 


r 


The  Air  Force  Avionics  Laboratory  has 
sponsored  many  efforts  to  develop  real/time 
Artificial  Intelligence  (AI)  systems.  One 
of  these  systems,  the  Adaptive  Tactical 
Navigation  (ATN)  program,  developed  a 
proto-type  system,  to  intelligently  control 
a  future  tactical  fighter's  integrated 
navigation  sensors.  ATN  was  developed  using 
a  distributed  communicating  expert  object 
architecture  called  the  Activation  Frame 
(AF) .  Using  the  AF  architecture,  ATN  was 
able  to  achieve  real-time  execution.  Real¬ 
time  execution  was  primarily  achieved  due 
to  the  AF' s  distributed  control  scheme 
which  eliminates  many  of  the  bottlenecks 
associated  with  centralized  schedulers. 
Unfortunately,  with  these  increased 
benefits,  there  is  increased  complexity 
associated  with  correctly  setting  the 
distributed  control  parameters.  The 
Engineering  Graphical  Analysis  Tool  <EGAT) 
was  developed  to  overcome  these  limitations 
by  providing  a  user  friendly,  graphical  AF 
development  tool.  EGAT  provides  the 
capability  to  dynamically  monitor  and 
mwdify  the  AF  control  parameters ■ 


This  paper  describes  the  Activation  Frame 
<AF)  architecture,  and  the  development  and 
implementation  of  the  Engineering  Graphical 
Analysis  Tool  (EGAT) .  The  EGAT  system  is 
used  to  dynamically  monitor  and  modify  the 
decentralized  control  parameters  of  the  AF 
architecture,  a  communicating  expert  object 
paradigm.  ^ 

2.  EGAT  DEVELOPMENT  PROGRAM 


Through  current  and  past  development 
efforts,  such  as  the  Adaptive  Tactical 
Navigation  (ATN)  and  the  Advanced  GPS 
Receiver  (AGR)  Programs,  the  Activation 
Frame  (AF)  architecture  has  demonstrated 
it's  suitability  to  implement  real-time 
intelligent  avionic  systems  [5] .  The 
Engineering  Graphical  Analysis  Tool  (EGAT) 
was  developed  to  alleviate  some  of  the 
problems  that  were  encountered  during  the 
development  of  these  real-time  avionic 
systems.  This  paper  will  describe  the 
utility  of  using  the  AF  architecture  to 
develop  real-time  intelligent  avionics 
systems.  In  addition,  the  EGAT  system  will 
be  described  in  detail .  Due  to  the  nature 
of  the  EGAT  system,  it  is  necessary  to 
understand  the  functionality  of  the  AF 
architecture.  The  next  section  will 
describe  the  AF  architecture.  This 
information  will  then  be  used  as  a  basis  to 
describe  the  EGAT  system. 

2.1  THE  ACTIVATION  FRAME  (AF)  ARCHITECTURE 
The  key  to  integrating  intelligent  systems 
into  conventional  avionic  platforms  is  to 
develop  efficient  mechanisms  which  insure 
real-time  operation.  The  Activation  Frame 


(AF)  architecture  was  created  to  give  real¬ 
time  AI  developers  the  capability  to 
efficiently  inclement  their  knowledge  based 
systems  while  satisfying  real-time 
constraints  [4] .  Early  attempts  to  develop 
real-time  machine  intelligence  systems 
relied  on  a  centralized  blackboard  scheme 
(Figure  1) .  Under  this  scheme,  an 
intelligent  blackboard  manager  would 
determine  which  expert  module  would  execute 
next.  Unfortunately,  under  the  centralized 
approach,  the  majority  of  the  processor 
time  was  used  by  the  scheduler.  Another 
major  problem  with  early  real-time  AI 
development  systems  is  that  they  were 
extremely  difficult  to  integrate  to 
conventional  sequential  software.  Most  of 
the  time  these  systems  ran  in  their  own 
environment  (usually  in  Lisp) ,  and  did  not 
interface  very  well  to  other  types  of 
software.  To  alleviate  these  problems, 
several  techniques  were  developed  which 
utilize  a  decentralized  control  scheme 
(Figure  1) .  One  of  these  schemes,  the 
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AF  architecture,  is  based  on  the 
Communicating  Expert  Object  paradigm.  The 
AF  architecture  utilizes  a  decentralized 
control  mechanism  to  provide  fast  efficient 
scheduling  and  context  switching  [3] .  This 
implies  that  the  control  knowledge  is  not 
located  in  one  central  area,  but  rather 
distributed  evenly  among  the  different 
modules  that  make  up  the  system.  This  is 
accomplished  through  a  message  passing, 
object  oriented  paradigm  in  which  the 
system  expertise  is  located  in  modules 
called  Activation  Frame  Objects  (AFOs) .  The 
AFOs  are  designed  to  work  In  much  the  same 
fashion  as  human  experts.  Each  AFO  has  a 
self  contained  knowledge  base  that  allows 
it  to  reason  about  a  specific  domain.  There 
is  no  shared  knowledge  or  common  memory 
between  the  AFOs .  In  order  to  communicate, 
prioritized  messages  are  sent  between  the 
different  AFOs  in  the  system.  In  addition, 
each  AFO  has  multiple  message  input  ports 
(Figure  2) .  These  multiple  input  ports 


28-2 


allow  the  real-time  AI  designer  to  set  up 
AND/OR  relationships  between  the  different 
input  ports  of  the  AFOs  to  insure  that  all 
of  the  information  needed  to  reach  a 
conclusion  is  available.  When  this  occurs, 
the  AFO  is  considered  to  be  primed,  and  the 
AFO  is  then  ready  to  receive  the  processor 
for  execution. 
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Every  AFO  is  made  up  of  four  functions: 
initialization,  priming,  importance,  and 
transfer  (Figure  3) : 

The  initialization  function  is 
responsible  for  setting  up  all  of  the 
AFO  communication  channels  and  initial 
control  values. 

The  priming  function  is  used  by  the  AF 
architecture  to  insure  that  an  AFO  has 
all  of  the  information  it  needs  to 
execute.  This  function  is  also 
responsible  for  setting  up  the 
AND/OR  relationships  between  the  AFO 
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Once  an  AFO  is  primed,  the  inqportance 
function  determines  the  overall  AFO 
importance  level  based  on  the 
individual  priorities  of  the  messages 
on  the  message  input  queues.  The 
default  importance  function  takes  the 
summation  of  all  the  message  priorities 
on  the  input  queues  to  determine  an 
overall  AFO  in^jortance  level.  However, 
this  can  be  modified  to  satisfy  a 
particular  application.  If  a  system  is 
primed,  and  it  has  the  highest  overall 
iitportance  level,  then  it  executes  it's 
transfer  function. 

The  transfer  function  is  responsible 
for  reading  in  the  AFO' s  input 
messages,  reasoning  over  the 
information,  and  sending  the  results  to 
the  other  AFOs  in  the  system. 

By  modifying  these  four  functions,  the 
real-time  intelligent  system  designer  has 
maximum  flexibility  to  tailor  the  AF 
control  structure  to  suit  his  purposes. 

A  collection  of  AFOs  that  work  in  a  common 
problem  area  is  called  a  subgraph  (Figure 
2) .  The  subgraphs  are  primarily  used  to 
partition  the  knowledge  base  in  a  logical 
manner  to  more  easily  visualize  complex 
problems.  The  subgraph  structure  parallels 
the  way  that  human  experts  work  in  a  group 
to  achieve  a  common  goal .  The  subgraph 
structure  does  not  place  any  physical 
restrictions  on  the  message  traffic  between 
the  AFOs.  An  AFO  in  one  subgraph  is  free 
to  communicate  to  an  AFO  in  any  other 
subgraph.  However,  for  multiple  processor 
environments,  the  subgraph  level  is  useful 
for  determining  the  proper  distribution  of 
AFOs  in  the  system. 
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As  seen  in  Figure  2,  a  collection  of 
subgraphs  form  an  AF.  In  the  AF 
architecture,  there  is  one  AF  per 
processor.  The  scheduling  of  the  AFOs  occur 
at  this  level.  However,  the  scheduling 
mechanism  is  considerably  different  than 
conventional  centralized  control  systems. 
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The  role  of  the  AF  scheduler  is  to 
determine  which  AFO  has  the  highest 
importance  level .  The  AFO  which  is  both 
primed  and  has  the  highest  importance  level 
will  execute  next.  Since  the  AFOs  calculate 
their  own  priming  and  importance  functions, 
the  AF  scheduler  does  not  have  to  contain 
any  domain  knowledge  about  the  individual 
AFOs.  This  results  in  a  very  fast, 
efficient  distributed  control  structure. 

For  multi-processor  environments,  there 
would  be  one  AF  per  processor.  Another  very 
attractive  feature  of  the  AF  architecture 
is  that  it  is  implemented  in  C  and  Ada 
versions.  This  makes  it  ideal  for  imbedded 
avionics  applications  because  it  can  be 
easily  integrated  into  existing  avionics 
software.  This  is  critical  for  future 
avionic  systems,  because  only  a  small 
portion  of  the  avionics  system  will  be 
related  to  machine  intelligence  (Fig^ure  4) 
[2] .  It  turns  out  that  integration  is  one 
of  the  major  problems  associated  with 
embedded  intelligent  systems.  The 
knowledge  engineer  is  usually  able  to  get 
the  individual  intelligent  modules  to  work. 
However,  when  the  system  is  integrated 
together,  it  is  very  difficult  to  get  the 
different  pieces  to  work  together. 
Con¥>ounding  this  problem  is  the  fact  that 
modern  intelligent  avionics  control  systems 
are  usually  made  up  from  a  mix  of 
heterogeneous  processors.  This  means  that  a 
CPU  may  need  to  talk  to  a  Signal  Processing 
Chip,  or  it  may  need  to  send  information  to 
a  graphic  display.  Because  of  this, 
integration  may  take  as  much  as  60  percent 
of  the  development  effort  [2] .  The  AF 
architecture  solves  this  problem  by 
providing  a  common  framework  between 
different  classes  of  processors.  The  AF 
architecture  has  been  successfully 
inplemented  on  PC's  all  the  way  up  to  fault 
tolerant  multi-processor  systems  (Figure 
5) .  The  hardware  underneath  the  AF 
architecture  is  hidden  from  the  user. 
Therefore  an  application  developed  for  one 
run  time  environment  can  be  easily 
transition  to  another  environment  as 
desired. 


2.2  EGAT  OVERVIEW 

As  described  above,  the  AF  architecture  has 
many  advantages  over  a  conventional 
centralized  architecture.  Unfortunately, 
with  this  increased  performance,  there  are 
also  some  difficulties  which  are  unique  to 
a  distributed  control  system. 

One  of  the  greatest  difficulties  is 
properly  setting  the  distributed  control 
parameters.  For  imbedded  intelligent 
avionic  systems,  it  is  critical  that  the 
proper  functions  are  executed  irt  a  timely 
fashion.  In  the  case  of  the  AF 
architecture,  the  message  flow  between  the 
AFOs  determine  the  AFO  execution  order. 
Because  of  this,  the  sending  order  and 
priority  of  the  AFO  messages  are  critical 
to  insure  the  correct  behavior  of  the 
intelligent  system.  If  the  priorities  of 
the  messages  are  not  correctly  set,  then  an 
important  message  may  be  lost  in  the 
system.  In  addition,  if  the  individual  AFO 
irqjortances  are  inappropriately  assigned, 
the  system  will  not  have  the  correct 
context  switching  to  insure  proper  focusing 
of  the  system,  and  important  AFOs  may  not 
execute  In  time.  The  task  of  selecting  the 
appropriate  message  and  AFO  importance 
priorities  is  very  arbitrary  and  heavily 
based  on  the  specific  domain  knowledge. 
Usually,  relative  importance  levels  are 
collected  during  the  knowledge  acquisition 
cycle  and  fine  tuned  during  rapid  proto¬ 
typing.  This  process  becomes  even  more 
complex  in  a  distributed  environment 
because  control  information  is  divided 
throughout  the  system.  Therefore,  when  one 
AFO  is  modified,  it  effects  all  of  the  AFOs 
in  the  system.  This  phenomena  makes  it 
extremely  difficult  to  fine  tune  the 
system.  The  EGAT  system  was  developed  to 
greatly  sinplify  the  development  of  real¬ 
time  AF  systems  [1]. 

2.3  EGAT  DESCRIPTION 

The  EGAT  system  is  a  graphical  analysis 
tool  which  allows  the  user  to  examine  the 
different  levels  that  make  up  the  AF 
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architecture.  When  the  program  is  first 
started,  the  EGAT  system  displays  the 
subgraph  level  (Figure  6) .  At  this  level, 
each  one  of  the  circles  represent  a 
subgraph  in  the  system.  For  this  particular 
exan^le,  there  are  four  subgraphs  shown: 
fraiMnaae,  Bodiai_h«alth,  pilot  lUMlth,  and 
In  addition,  wh^n  tne  EGAT 
system  is  running,  there  will  be  colored 
lines  between  the  subgraphs  that  represent 
the  level  of  inter-subgraph  communication. 
These  colors  follow  the  color  spectrum  with 
purple  representing  the  lowest  message 
traffic  all  the  way  up  to  red,  representing 
high  message  traffic.  Determining  the 
amount  of  message  traffic  between  the 
subgraphs  is  extremely  useful  for 
distributing  the  subgraphs  on  multiple 
processors.  By  minimizing  the  inter¬ 
subgraph  communication,  the  inter-processor 
communication  can  also  be  minimized  when 
the  subgraphs  are  placed  on  different 
processors . 

At  the  corners  of  the  EGAT  system  are  the 
four  action  boxes:  halt,  step,  and 

quit.  The  halt  action  box  allows  the  user 
to  freeze  a  running  AF  system  at  any  time 
to  examine  its  current  state.  While  the 
system  is  halted,  the  user  can  single  step 
through  the  system  by  selecting  the  step 
action  box.  The  action  box  allows  users 
to  move  from  lower  levels  of  the  EGAT 
display  to  higher  levels  (i.e.  AFO  level  to 
subgraph  level) .  And  finally,  the  quit 
action  box  allows  the  user  to  exit  the 
system.  These  four  action  boxes  are 
available  at  every  level  of  the  EGAT 
system. 

For  more  detailed  information  about  the 
individual  AFOs  that  make  up  the  different 
subgraphs,  the  user  can  use  a  mouse  to 
select  a  particular  subgraph.  At  this 
point,  the  EGAT  system  will  display  the  AFO 
Level  (Figure  7) .  In  the  AFO  Level,  each 
AFO  is  represented  by  a  circle.  For  the 
example  display  shown  in  Figure  7,  there 
are  six  AFOs  shown.  Each  one  of  the  AFOs 
is  made  up  of  an  inner  and  outer  circle. 


The  inner  circle  represents  the  current  AFO 
state.  As  described  earlier,  every  AFO  in 
the  system  will  be  in  one  of  three  states: 
inactive,  primed,  or  running,  represented 
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by  a  green,  yellow,  or  red  color 
respectively.  Additionally,  every  AFO  has 
an  outer  circle  which  graphically  shows  the 
AFO' s  current  importance  level.  These 
levels  are  represented  by  one  of  seven 
colors  in  which  purple  is  the  lowest  value, 
following  the  color  spectrum,  all  the  way 
up  to  red  representing  the  highest  overall 
AFO  inqportance  level.  Furthermore,  every 
AFO  in  the  system  has  a  set  of  eight 
attached  lines  representing  the  AFO's  input 
ports.  When  one  AFO  sends  a  message  to 
another  AFO  in  the  subgraph,  a  flashing 
line  will  appear  from  the  center  of  the 
sending  AFO  to  the  appropriate  input  port 
of  the  receiving  AFO.  This  allows  the  EGAT 
user  to  trace  the  message  flow  between  the 
different  AFOs  in  system.  If  the  user 
wishes  to  determine  the  contents  of  the 
message  or  more  detailed  information  about 
an  AFO,  then  by  using  the  mouse  to  select  a 
particular  AFO,  the  AFO  Information  Level 
will  be  displayed. 

The  AFO  Information  Level  is  responsible 
for  displaying  all  of  the  detailed 
information  about  an  AFO.  For  the  exanple 
shown  (Figure  8),  the  AFO,  a_pr«viou8_ 
waypoint,  contained  in  the  subgraph, 
aK>a*  boaitb,  has  a  current  importance  level 
of  2T.  In  addition,  the  AFO  also  has  two 
active  input  ports  with  no  current  messages 
on  either  port .  The  <-  and  ->  boxes  are 
used  to  view  and  scroll  text  longer  than 
the  size  of  the  message  display  box.  The 
PRKV  and  the  MBXT  boxes  allow  the  user  to 
switch  between  the  different  messages  on  a 
particular  input  queue.  This  condition  will 
occur  if  several  low  priority  messages  are 
sent  to  a  particular  input  queue  or  if  the 
AFO  is  not  primed.  In  order  to  use  either 
the  <-,— >  or  PR>V,mn  boxes,  the  user  must 
first  select  the  appropriate  message  input 
port  by  "clicking"  on  it  once  with  the 
mouse.  After  this  the  message  input  port 
will  become  active  and  the  scrolling 
functions  will  be  activated. 
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manually  examine  the  inter  AFO-message 
traffic  to  determine  if  the  system  was 
functioning  as  desired.  If  any  AF 
parameters  needed  to  be  modified,  they 
would  have  to  go  back  and  modify  the 
original  source  code,  re-compile  the  code, 
rerun  the  system,  and  manually  analyze  the 
results  (Figure  9) .  If  the  wrong  parameters 
were  selected,  they  would  have  to  repeat 
this  whole  process  again.  Needless  to  say 
this  was  a  very  length,  arduous  process 
that  limited  the  effectiveness  of  AF 
design.  With  the  EGAT  system,  the  user  does 
not  have  to  manually  analyze  the  results  of 
the  run-time  system.  With  EGAT's  single 
step  and  halt  capabilities,  the  developer 
can  insure  that  the  run-time  system  is 
functioning  as  desired.  If  some  of  the  AF 
control  parameters  need  to  be  modified,  the 
developer  can  change  the  parameters, 
without  reconciling  the  system.  In  this  way 
the  developer  can  see  the  results  of  his 
changes  in  real-time.  Clearly  providing  the 
ability  to  single  step  and  dynamically 
modify  AF  control  parameters  are  the  most 
useful  features  of  the  EGAT  system. 


The  real  power  of  the  EGAT  system  is  not  in 
its  ability  to  just  examine  the  inter¬ 
workings  of  a  running  AF  system,  but 
rather,  its  ability  to  dynamically  alter 
the  AF's  control  and  message  passing 
parameters.  As  described  earlier  in  the 
paper,  one  of  the  key  difficulties 
associated  with  using  the  AF  architecture 
and  other  distributed  control  systems  is  to 
correctly  set  the  control  parameters.  In 
order  to  properly  set  up  the  AF  control 
mechanisms,  the  real  time-AI  designer  must 
select  the  correct  overall  AFO  importance 
levels  and  the  individual  AFO  message 
activation  levels.  In  addition,  the  real 
time  designer  must  be  concerned  that  the 
priming  and  importance  functions  have  been 
correctly  set  to  insure  the  proper  focusing 
of  control  svstem.  With  the  EGAT  system, 
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the  user  can  freeze  the  system  (halt  action 
box)  and  go  into  the  AFO  Information  level 
to  modify  the  AF  control  parameters. 

Before  the  development  of  the  EGAT  system, 
real-time  intelligent  system  developers 
were  forced  to  run  their  system  and  capture 
the  inter-AFO  messages  to  a  file.  One  this 
was  accomplished,  they  would  have  to 


3.0  PROGRAM  STRUCTURE 


This  section  of  the  paper  will  focus  on  the 
structure  of  both  the  AF  architecture  and 
the  EGAT  system. 

3.1  AF  STRUCTURE 

In  order  to  understand  the  overall 
structure  of  the  EGAT  system,  it  is 
important  to  understand  the  basic  structure 
of  the  AF  architecture.  The  EGAT  system 
interfaces  directly  to  the  AF  architecture 
which  allows  manipulation  of  the  data 
structures,  and  provides  halting  and  single 
stepping  functionality  to  the  running  AF 
system.  The  major  data  structures  of  the  AF 
system  are  shown  in  Figure  10.  At  the 
heart  of  the  AF  architecture  is  the 
frm_8truct  structure.  There  is  one 
frm_struct  structure  per  processor.  The 
£zm_struct  points  to  the  a£  struct 
structure  and  the  ptb_8trucF  structure. 

The  a£_struct  structure  contains  all  of  the 
internal  details  of  a  single  AFO.  There  is 
one  unique  a£_8truct  structure  for  every 
AFO  in  the  system.  In  addition  to  the 
a£_8tract  structure,  the  £m_8truct 
structure  also  points  to  the  port  table 
structure,  ptb_struct.  As  described 
earlier,  every  AFO  in  the  system  has  at 
least  one  message  input  port .  Each  message 
input  port  has  a  unique  entry  in  the  port 
table  structure,  ptb  Struct.  In  this 
manner,  any  AFO  in  tlTe  system  singly  needs 
the  name  of  the  destination  AFO  to  send  a 
message.  The  data  in  the  ptb  struct  is 
used  to  get  the  destination  aFo's  port 
structure,  pt_8truct.  The  pt_Struct 
structure  hangs  directly  off  of  the 
•£_8truct  structure  and  is  used  to  store 
the  AFO' s  incoming  message .  There  is  always 
one  pt_8truct  that  corresponds  directly  to 
an  AFO  input  port .  Linked  to  the  port 
structure  is  the  actual  AFO  messages.  These 
messages  are  stored  in  the  msg  struct 
structure.  The  awg_struct  structure 
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contains  several  iir^ortant  fields 
associated  with  the  AFO  messages.  They  are 
as  follows:  the  message  importance  level, 
■so  act;  the  length  of  time  the  message  is 
valTd,  aay  daad;  and  the  actual  message 
data,  —gjgbl.  The  ■sq  ool  field  contains  a 
pointer  to  elements  called  Generalized 
Objects  (GOs) .  GOs  were  developed  as  a 
means  to  transfer  data  elements  between 
heterogeneous  con^uters .  The  GO  is  made  up 
of  a  Data  Description  Language  (DDL)  and  a 
pointer  to  the  data.  The  DDL  tells  the 
receiving  computer  how  much  and  what  type 
of  storage  to  allocate  for  the  message.  In 
this  fashion,  the  message  passing  between 
different  types  of  computers  become 
transparent  to  the  user. 


The  structure  of  the  EGAT  system  is  shown 
in  Figure  11.  The  EGAT  internal  data 
structures  closely  resemble  the 
hierarchical  nature  of  the  AF  architecture. 
The  RBU)  DATA  structure  stores  the 
informatTon  to  be  displayed  in  the  subgraph 
level.  Contained  in  the  HEAD  DMA  structure 


are  several  major  fields  that  enable  EGAT 
to  access  and  graphically  represent  the  AF 
architecture.  The  two  fields  that  enable 
EGAT  to  directly  interface  to  the  AFO 
system  are  afnaae  and  af^^nuaber.  With  this 
information,  EGAT  can  gaTn  direct  access  to 
the  £zm_stzuct  of  the  AF  architecture . 
Additionally,  the  a, y, radius,  numbar  a£o, 
Jtay,  and  lina_stsuct  fields  are  used~by  the 
EGAT  system  to  store  graphical  information. 
In  addition  to  the  subgraph  information, 
the  BEAD  DATA  structure  also  contains  a 
pointer  Yield,  afo  ptr,  to  the  different 
AFOs  that  make  up  Ine  subgraph.  The  AFO 
information  is  contained  in  the  ArO_DATA 
structure.  This  structure  is  responsible 
for  displaying  the  AFO  Level  of  the  EGAT 
system.  The  primary  fields  of  the  AFO_DATA 
structure  are  as  follows:  afnaiaa,  afonaaa, 
and  afo  numbar  fields  are  used  to  directly 
access  Yhe  AFO  architecture;  x,y, radius, 
kay,  iaiport_kay,  and  ijqport  tazt_Icay  fields 
are  used  foY  EGAT  graphic  cfTsplays;  and 
finally  the  box  field  points  to  the 
B0K_DATA  structure.  The  BOX  DATA  structure 
is  Yesponsible  for  storing  Yhe  information 
needed  to  display  the  EGAT  AFO  Information 
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Level.  The  majority  of  the  fields  in  this 
structure  are  responsible  for  holding 
graphic  information  that  is  necessary  to 
display  and  scroll  text  and  graphics.  In 
addition,  the  afopoint  field  points  back  to 
the  parent  AFO.  Through  this  pointer,  the 
EGAT  system  can  interface  directly  to  the 
AF  architecture  at  the  AFO  Informational 
Level . 

4.0  EGAT  OPERATION 

The  EGAT  system  connects  directly  into  the 
AF  architecture,  which  not  only  allows  the 
monitoring  of  the  running  AF  system,  but 
also  gives  the  user  the  ability  to  modify 
the  AF  system  to  obtain  efficient  and 
correct  operation.  This  is  extremely  useful 
when  developing  eirioedded  intelligent 
avionics  systems  because  it  allows  the 
developer  to  see  the  internal  workings  of 
the  system  before  it  gets  inserted  into  an 
embedded  environment.  With  EGAT,  the  system 
designer  can  develop  a  system  in  a 


workstation  environment,  and  then 
transition  his  application  to  other 
platforms . 

EGAT  was  designed  to  be  easy  to  operate  and 
user  friendly,  thus  providing  useful 
insight  into  the  operation  of  the  AF 
system.  After  startup,  EGAT  can  be  used  to 
monitor  the  running  AF  operation.  The  AF 
system  can  either  be  examined  in  a  free 
running  mode  or  the  system  can  be  single 
stepped  in  order  to  analyze  performance  in 
detail.  The  free  running  mode  is  useful 
for  determining  the  flow  of  the  overall 
system.  The  AF  architecture  provides  an 
excellent  environment  for  distributing 
different  tasks  on  multiple  processors.  The 
free  running  mode  can  be  used  to  help  the 
designer  determine  which  tasks  should  be 
placed  on  multiple  processors.  The  AF 
system  runs  in  real-time  with  the  message 
traffic  represented  at  the  Subgraph  Level 
by  the  changing  colored  lines  between  the 
subgraphs . 


28-8 


A  more  effective  way  of  determining  the 
meseage  by  message  operation  of  the  AF 
system  is  in  the  single  step  mode.  In  this 
mode  the  AF  system  is  halted  and  allows  the 
user  to  see  the  static  effect  of  all 
message  passing.  In  this  mode  the  correct 
operation  can  be  determined  because  it  is 
easy  to  see  what  effects  the  messages  have 
on  the  system. 

Several  types  of  AF  control  problems  can  be 
analyzed  quickly  with  EGAT,  Including 
bottlenecks,  livelock,  and  starvation 
conditions.  A  bottleneck  occurs  when  an 
AFO  has  a  large  number  of  in^ortant 
messages  in  its  input  queue,  but  does  not 
have  all  of  the  information  it  needs  to  be 
primed.  In  this  case,  the  AFO  will  have  a 
high  importance  level;  however,  it  will  not 
even  be  considered  for  execution.  EGAT  can 
help  in  determining  the  bottleneck 
situation  by  observing  which  AFOs  have  an 
internal  green  circle,  meaning  that  they  do 
not  have  the  information  needed  to  become 
primed,  but  at  the  same  time  have  a  red  or 
orange  outer  ring  meaning  that  their 
importance  is  high.  If  this  state  persists 
then  it  shows  that  this  AFO  is  not  getting 
the  information  needed  to  run  and  is  a 
bottleneck.  This  situation  can  be  helped 
by  going  into  the  AFO  information  level  on 
the  bottleneck  AFO  and  injecting  messages 
to  prime  the  AFO.  From  this  the  effects  on 
the  AF  system  can  be  determined. 

The  next  condition,  livelock,  occurs 
because  an  AFO's  importance  level  is  not 
properly  set  and  does  not  drop  enough  to 
release  the  processor  after  it  has  sent  out 
its  messages.  In  addition,  this  condition 
could  also  result  from  a  group  of  AFOs 
continuing  to  loop  processor  control 
amongst  themselves  and  never  releasing  the 
processor  for  other  AFOs.  Livelock  can  be 
determined  by  an  AFO  releasing  its  messages 
and  irrcnediately  returning  to  a  primed  and 
then  running  state  without  any  other  AFO 
having  a  chance  to  obtain  the  processor. 
This  situation  can  be  helped  by  going  into 
the  running  AFO's  Information  Level  and 
forcing  its  importance  level  down.  This 
will  allow  another  AFO  with  a  higher  AFO 
importance  level  to  run.  A  similar  method 
can  be  used  to  break  out  of  a  loop  by 
reducing  the  importance  level  of  several  or 
all  of  the  AFOs  in  the  loop  to  allow  an 
AFO  outside  of  the  loop  to  get  the 
processor.  The  effects  on  the  system  can 
then  be  observed. 

The  last  condition,  starvation,  occurs  when 
an  AFO  is  primed,  but  never  gets  a  chance 
to  execute.  Starvation  can  be  determined 
with  EGAT  by  observing  an  AFO  or  several 
AFOs  that  are  primed  for  long  periods  of 
time  but  never  obtain  a  hi^h  enough 
importance  to  run.  This  situation  is 
represented  graphically  by  the  AFOs 
internal  circle  being  yellow,  meaning  it's 
primed,  and  it's  outside  ring  never  reaches 
higher  than  a  purple,  blue  or  light  green, 
meaning  the  AFOs  importance  does  not  reach 
a  sufficient  importance  level  to  run.  A 
fix  to  this  situation  is  to  go  to  the  AFO 
Information  Level  and  increase  the 
importance  level  of  the  AFO  to  see  the 
effects  on  the  system. 

As  can  be  seen  by  these  debugging  features 
EGAT  is  very  useful  to  provide  insight  into 


the  inter-workings  of  the  AF  system.  From 
these  insights,  major  bugs  in  the  running 
system  can  be  found  and  corrected  while  the 
system  is  still  running.  The  effects  are 
then  determined  and  allows  the  designer  to 
more  permanently  fix  the  external  files 
that  contain  the  AFO  and  message 
iirqportances .  This  ultimately  allows  the 
system  designer  to  develop  more  efficient 
and  effective  AF  systems. 

5.0  Real-Time  AI  Development  Issues 

Before  real-time  embedded  AI  systems  can  be 
integrated  into  avionics  applications,  two 
major  issues  need  to  be  addressed,  namely 
verification/  validation  and  maintenance  of 
real-time  embedded  intelligent  systems. 
Currently,  verification  and  validation 
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issues  are  difficult  enough  for 
conventional  sequential  software,  let  alone 
data  driven  distributed  intelligent 
systems.  Most  intelligent  systems  that  are 
developed  for  real-time  operation  tend  to 
embed  the  knowledge  base  Into  the  inference 
engine  in  order  to  increase  performance  of 
the  system.  This  makes  it  extremely 
difficult  to  initially  verify  and  validate 
the  run-time  code,  and  nearly  in^ossible  to 
maintain  the  code  as  the  knowledge  in  the 
system  is  modified.  In  order  to  overcome 
these  limitations,  the  Avionics  Laboratory 
is  sponsoring  several  contractual  efforts 
to  examine  methodologies  to  verify, 
validate  and  maintain  real-time  intelligent 
systems.  The  first  of  these  programs. 
Knowledge  Representations  into  Ada 
Methodologies  (KRAM) ,  developed 
methodologies  to  verify  the  knowledge  base 
and  automatically  transition  it  into 
efficient  Ada  code  using  the  AF 
architecture  as  the  run-time  system.  The 
second  major  program.  Shell  for  Knowledge 
Representation  into  Ada  Methodologies 
(SKRAM) ,  is  developing  an  integrated 
development  maintenance  environment  based 
on  the  research  performed  under  the  KRAM 
effort  (Figure  12) .  The  EGAT  system  will  be 
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embedded  platform. 

The  intent  of  the  EGAT  tool  and  our  other 
real-time  AI  development  tools  are  to  shed 
some  light  on  the  problem  of  transitioning 
real-time  AI  systems  from  the  laboratory 
into  the  operational  environment.  With  the 
use  of  the  KRAM  and  SKRAM  environments,  the 
knowledge  engineer  can  verify  and  validate 
his  knowledge  base  and  automatically 
convert  the  knowledge  base  into  Ada  code 
using  the  AF  architecture  as  the  basic  run¬ 
time  system.  At  this  point  the  knowledge 
engineer  can  use  the  EGAT  tool  to  tune  the 
AF  control  parameters.  After  this,  the  run¬ 
time  system  can  be  placed  on  a  multiple 
processor  environment  to  increase  run-time 
performance.  In  this  way,  we  hope  to 
provide  a  complete  transition  path  from  the 
laboratory  to  the  operational  environment 
(Figure  13) . 
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6.0  Conclusions 

As  the  complexity  and  amount  of  information 
needed  to  control  complex  avionics  systems 
increase,  so  will  the  need  increase  for 
intelligent  real-time  software  to  help  in 
the  management  of  these  systems.  In  order 
to  take  maximum  advantage  of  available 
resources  and  satisfy  real-time 
constraints,  more  real-time  intelligent 
systems  are  moving  towards  a  decentralized 
control  scheme.  Because  of  the  increased 
con^lexities  associated  with  decentralized 
distributed  control,  the  EGAT  system  was 
developed  to  aid  knowledge  engineers  and 
system  developers  in  the  development  of 
real-time  embedded  avionics  systems.  The 
EGAT  system  provides  a  user  friendly 
environment  to  interact  with  and  modify  a 
running  AF  architecture.  For  the  reasons 
described  above,  the  AF  Architecture  i.-'- 
ideally  suited  for  real-time  imbedded 
avionics  systems.  With  it's  ability  to  run 
in  either  an  Ada  or  C  environment,  it's 
modular  design,  and  it's  distributed 
control  scheme,  the  AF  architecture  will 
provide  an  excellent  run-time  environment 
for  em)3edded  intelligence  avionics  systems. 
The  only  major  difficulty  associated  with 
the  AF  architecture  and  other  distributed 
systems  is  the  increased  complexity 
associated  with  setting  up  the  initial 
distributed  control  scheme.  With  the 
development  of  the  EGAT  system,  the  system 
designer  has  the  capability  to  develop  and 
debug  his  system  on  a  workstation 
environment,  then  transfer  it  to  an 


28-10 


1990. 

4.  Green,  P.E.,  "AF:  A  Framework  for  Real- 
Time  Distributed  Cooperative  Problem 
Solving",  in  Distributed  Artificial 
Intelligence,  ed.  M.N.  Huhns,  pp.  153-175, 
Pitman  Publishing,  London,  England,  1987. 

5.  Final  Technical  Report  for  AF/WRDC  under 
Contract  No.  F33615-86-C-1043,  The  Analytic 
Sciences  Corp.,  Reading,  MA,  February, 

1990. 

6.  Green,  P.E.  and  W.R.  Michalson,  "Real- 
Time  Evidential  Reasoning  and  Network  Based 
Processing,”  Proc.  IEEE  First  Annual  Conf. 
on  Neural  Networks,  San  Diego,  CA,  June 
1987. 

7.  "Knowledge  Representation  into  Ada 
Parallel  Processing,"  Final  Report  under 
NASA  Contract  NASA-18565  Task  10,  The 
Charles  Stark  Draper  Laboratory,  Inc., 
Cambridge,  MA  1990. 

8.  "Validation  and  Verification  of 
Intelligent  Systems  Using  Evidence  Flow 
Graph  Techniques,"  Final  Report  under  NASA 
Grant  NAG-1-964,  Worcester  Polytechnic 
Institute,  Worcester,  MA  1990. 

9.  Green,  P.E.,  D.P.  Glasson,  J.M. 

Pomerade,  and  N.A.  Acharya,  "Real-Time 
Artificial  Intelligence  Issues  in  the 
Development  of  the  Adaptive  Tactical 
Navigator,"  Proc.  Space  Operations- 
Automation  and  Robotics  Workshop,  NASA 
Johnson  Space  Center,  Houston,  TX,  August 
1987. 


I 


i 


CQNHINENT  PART  NOTICE 


This  paper  is  a  COMPONENT  PART  of  the  follomins  COMPILATION  report: 


The  component  PART  is  provided  here  to  alljow  users  access  to  individually 

AUTHORED  SECTIONS  OF  PROCEEDINOS^  ANNAL5>  SYMPOSIA^  ETC*  HoWEVER>  THE 
COMPONENT  SHOULD  be  considered  within  the  context  of  THE  OVERALL  COMPILATION 

REPOiTT  AND  NOT  AS  A  STAND-ALONE  TECHNICAL  REPORT* 

The  followins  COMPONENT  PART  numbers  comprise  the  COMPILATION  report: 


AD#;  TITLE!.. 


33  I 

/JP"  33*7 

AP"  Co 

P66b  3 

3,  <9_5- 

/fitXy Pqo ^  3 

3  Ss— 


A  KNOWLEDGE-BASED  INTELLIGENT  TUTORING  SYSTEM:  ACQUIRE™-ITS 


B.A.  Schaefer,  R.  Side,  R.  Wagstaff,  O.  Magusin,  &  I£.  Morrison 
Acquired  Intelligence  Inc 
#205-1095  McKenzie  Ave 


Victoria,  B.C.  V8P2L5 
Canada 


91-15535 

illllllll 


I. -SUMMARY  / 

Acquired  Intelligen^Inc^td^^veloped  an  automated 
knowledge  acqukitm^^stem  and  expert  system  shell  known 
as  ACQUIRE*^  A'^ject  has  been  undertaken  to  extend  the 
ACQUIRfc™^stem  for  use  as  a  domain  independent, 
knowledge -based  Intelligent  Tutoring  System.  The  intent  of 
this  (KOject  was  to  provide  the  tools  that  would  enable 
corpenate  or  governmental  personnel  to  npMIy  develop  their 
own  expert  system  knowledge  bases  and  nqtidly  convert  these 
knowledge  bases  for  use  ii.  task/case  oriented  training.  A 
majw  thrust  of  this  project  was  to  provide  tools  that  would 
enable  computer  users,  rather  than  computer  professionals,  to  q 
devek^  the  training  packages.  This  extension  to  ACQUIRE****^ 
has  involved  the  development  of  two  major  modules:  the 
Curriculum  Author  Module,  and  the  Tutoring  Module.  '3 


Using  the  Curriculum  Author  Module  experts  or  instn^tar^^ 
o  able  to  develop  a  curriculum  composed  of  lessoit&iir^case- 
— siQ^rgrproach.  The  system  is  oriented  toward 'learning  by 
drdii^,  i.e.,  students  learn  by  solving  actual  cases  -  sui^rted 
by  simulation  if  required.  iThese  cases  ate  packaged  into 
tesons  by  the  expert  to  demonstrate  important  and  related 
concepts.  TtwCypsuIw  Author,  utilizes  the  structure  and 
agdMt  ufin^expert  knowledge  base  to  help  the  expert  select 
’'m  best  cases  to  package  together  into  lessons. 

9^  V- 

'  The  Tutoring  Mothde  monlbrs  a  studen^ progress  in  solving 
cases  and  constructs  a  ippesentatiofiQfuie  student’s  growing 
knowledge  as  a  "naive"  ACQUIRE™  knowledge  base^^c 
TUtming  Module  gradually  merges  the  student’s  naive 
knowledge  base  with  the  expert’s  by  identifying  inctxrect  rules, 
gaps  in  the  knowledge,  and,  most  importantly,  poor  structuring 
of  the  knowledge  (Le.,  incorrect  packaging  of  rules)  which 
indicates  misconcqMions  about  how  knowledge  should  be 
used.  The  TutOTing  Module  accomplish’s  this  merger  by 
selecting  and  presenting  approfniate  cases,  from  the  lessons 
coflsinicied  by  the  expert,  to  help  the  student  elucidate  the 
correct  knowledge  in  active  problem  solving.  Additionally,  the 
Tutoring  Module  explicitly  demonstrates  differences  between 
die  student’s  knowledge  base  and  die  expert's. 

ACQU1RE™-ITS  is  written  in  the  C  ftogranuning  Language 
for  execution  on  personal  computen  running  MS-DOS  or 
UNK.  The  ^rslem  has  an  X-Window  interfiaoe  and 
incorporates  hypermedia.  ACQUIRE^-ITS  is  desigiwd  such 
that  it  is  applk^le  to  a  broad  range  of  industrial  and 
govemmaual  qiplications.  As  with  ACQUIRE™,  these 
intelligedt  training  applications  win  be  available  on  affordable 
computers  and  win  be  developed  directly  by  die  experts. 


A  client  of  Acquired  InieUigence  Inc  expressed  significant 
interest  in  the  development  of  a  cost  effective  environment  for 
building  intelligent  tutoring  applications.  This  client  required 
knowledge-based  inteUigent  mtoring  in  an  environment  that 
wiU  enable  computer  usm,  rather  than  computo-  professionals, 
to  develop  the  knowledge  bases  and  training  courses. 

The  past  decade  has  realized  technological  developments  that 
facilitate  delivery  of  these  requirements.  Knowledge-based 
systems  have  come  into  routine  use  while  intelligent  tutoring 
systems  have  realized  their  first  commercial  successes  [1]. 
During  this  period  both  knowledge-based  systems  and 
intelligent  tutoring  systems  were  employed  in  training,  each 
with  their  own  strengths  and  weaknesses.  Knowledge-based 
systems  technology  had  developed  to  the  point  that  numerous 
domain  independent  shells  existed  to  assist  in  the  develt^ment 
of  applications;  however,  the  technology  was  not  designed  with 
training  in  mind.  The  training  capability  of  knowledge-based 
'.ystems  relied  exclusively  on  human  learning  capabilities  laiher 
than  on  inherent  instructional  techniques.  Intelligent  tutoring 
systems  were  designed  speciffcally  for  training,  however,  the 
technology  had  not  advanced  as  far  as  the  creation  of 
intelligent  tutoring  system  shells.  Applications  were 
handcrafted  and  consequently  extremely  costly  to  produce. 

These  technological  developments,  along  with  growing 
demand  from  industry  for  cost-effective  computerized  training 
tools,  prompted  Clancey  [2]  to  propose  knowledge-based 
intelligent  tutoring  systems  as  a  practical  solution  applicable  to 
a  wide  variety  of  industrial  problems.  Knowledge-based 
intelligent  tutoring  systems  employ  the  knowledge  rquesented 
in  expert  system  applications  as  tite  subjea  matter  to  be  taught 
In  these  systems,  the  student  learns  in  appienticeshq)  fashion 
by  examining  cases  run  through  the  inference  engine.  The 
tutoring  component  guides  and  queries  students  about  their 
understanding  throughout  the  execution  of  a  case,  as  well  as 
across  cases. 

Gancey  argued  that  the  focus  of  student  learning  should  be  die 
correct  conclusions  to  draw  in  a  wide  variety  of  dicumstances 
and  the  factors  involved  in  determining  those  conclusions.  To 
this  end,  his  method  employs  case-based  instruction  to  give  the 
student  "experience"  in  situations  that  make  important  aspects 
of  expert  knowledge  expUcit  He  has  found  di^  much  of  the 
necessary  information  required  to  teach  expert  knowledge  is 
inherent  in  the  knowledge  bases  of  existing  expert  systems. 
Gancey  constructed  a  number  of  special  purpose  programs  to 
extract  such  information,  from  knowtedge-bases  impleniented 
in  the  M.l  expert  system  shell,  for  use  in  instruction. 
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This  aiiixoach  opens  up  the  pos^ility  of  creating  generic, 
intelligent  tutoring  system  shells,  like  those  for  expert  systems. 
Oancey  has  demonstrated  that  this  approach  represents  a  real 
instmctioiial  alternative  to  Daditkmal  instruction  methods, 
automated  or  otherwise.  Given  die  early  stage  of  this  research, 
however,  there  remain  limitations  to  this  ^(noacb. 

Rrst,  die  approach  is  best  suited  to  teaching  specific  skills 
radier  than  general  overviews  of  various  fields.  Given  the 
number  of  specific  skills  for  which  training  is  in  shmt  suj^ly, 
this  restriction  is  not  a  real  hindrance  to  the  utility  of  the 
approach. 

Second,  the  qiptoach  inbrnts  the  central  liinitation  of  expert 
system  technology  -  the  knowledge  acquisidon  problem.  It  is 
very  difficult  and  time  consuming  to  acquire  knowledge  fiom 
domain  experts,  and  it  is  similarly  difficult  to  construct  a  well 
structured  knowledge  base  that  provides  complete  and 
thorough  coverage  of  the  problem  domain.  Clancey’s 
qiproacb  relies  on  die  assumption  that  a  knowledge  engineer 
hu  performed  an  adequate  job  of  eliciting  domain  knowledge 
fiom  an  expert  and  {Roduced  a  well  structured  and  complete 
knowledgebase.  Tto  is  a  time-consuming  and  error-prone 
process  that  rqxesents  a  more  serious  limitadon  to  the  utility  of 
knowledge-based  intelligent  tutming  system  technology. 
However,  with  die  advent  of  automated  knowledge  acquisidmi 
systems  [3]  it  has  become  much  more  reasonable  for  experts  to 
develop  well  structured  and  accurate  knowledge  bases  on  dieir 
own. 

Third,  given  that  the  system  described  by  Gancey  only  permits 
case  execution,  queries  on  case  execudon,  and  receding  of 
student  perfwmance.  it  could  be  viewed  as  more  of  an 
intelligent  testing  system  rather  than  an  intelligent  tutoring 
system.  This  type  of  system  would  benefit  gready  if  the 
knowledge  base  was  augmented  with  muldroedia  background 
information,  in  the  form  of  text,  grtqihics  and  video.  This 
could  be  realized  if  this  background  information  was  in  turn 
available  to  die  authoring  system  for  inclusion  in  courses  and 
lessons  and  then  executed  by  the  tutoring  system. 

FurthetiiKHe,  Clancey  makes  little  use  of  student  modelling  to 
help  guide  instruction,  leaving  instruction  exclusively  to  human 
instructors  to  specify  through  die  authoring  facility.  This 
requires  conadentbte  effort  fiom  the  instructor  to  anticipate  all 
of  the  possible  points  of  confusion  that  students  may  encounter 
and  to  provide  cases  that  cover  them  aU. 

The  pragmatic  approach  that  Clancey  has  taken  provided  a 
good  starting  point  for  development  of  the  tequM  tools. 
However,  we  needed  to  overcome  some  of  the  limitations  of 
his  approach  to  produce  a  truly  robust  system  for  practical  use. 
A  central  concern  was  the  knowledge  acquisition  problem.  To 
alleviate  this  problem  the  decision  was  taken  to  base  the 
inteUigait  tutoring  system  on  the  ACQUIRET**  expert  system 
environment  [3,4]  (described  below).  ACQUIRE^**  deals 
expfiddy  with  the  acquisition  of  domain  knowledge  fiom 
human  eiqierts,  making  the  adapted  system  easier  and  filter  to 
use  by  a  broad  audience. 

To  extend  the  ACQUIRE"' eqieit  system  envnonment  for 
jmeWjent  tutoring  purposes  (ACQUIRE"*-ITS)  three  new 
fflodnleB  were  developed:  the  Tutor,  the  Curriculum 
AuihoryBdimkypmmilia  module.  These  modules  were 
toterlhced  to  die  Knowledge  Acquisition  System  end  dm  Expert 


System  Shell  that  currently  make  up  the  commercially  availaUe 
ACQUIRE™  system. 

The  Curriculum  Author  module  enables  the  user  to  consinia 
case-miented  courses  and  lessons.  The  Tbtrx' guides  the 
student  tbrou^  these  cases  until  the  student  can  perform  like 
an  expert  The  system  is  interfaced  to  the  Hypermedia 
environment  with  die  potmtial  to  enhance  communication  with 
the  user  through  text  grtphics,  video  informatimi,  and 
knowledge-based  simulation.  In  its  simplest  form,  the  user  is 
able  to  access  linked  textual  and  grqdiic  information  located  in 
the  knowledge  base;  enhanced  versions  of  the  Hypermedia 
interface  will  include  animation  and  video  ctpabilify. 
Hypermedia  environments  are  ctpable  of  r^iresenting  object- 
miented  grtqdiical  simulations  which  in  turn  could  be  driven  by 
the  Expert  System  ShdL  A  siniilar  approach  was  used 
efiecdvdy  by  Towne  and  Munro  [S]  in  the  implementatioo  of 
the  Intelligent  Maintenance  Training  System  for  die  blad^old 
system  of  helicopters  in  the  US  Navy. 

The  major  strength  of  this  qiptoach  is  a  solution  to  the  critical 
restriction  of  knowledge-based  intelligent  tutoring  systems,  the 
knowledge  acquisition  bottleneck.  The  knowledge  acquisition 
capahiliries  of  ACQUIRE™  are  utilized  to  extract  expertise 
fiom  experts  direcdy,  without  undergoing  the  tune-consuming 
process  of  conventional  knowledge  acquisition.  ACQUIRE™ 
strengthens  the  approach  by  producing  highly  structured 
knowledge  bases  construct^  with  a  strong  methodological  bias 
towards  thmoughness  and  completeness  of  domain  knowledge. 
This  reduces  the  need  to  add  knowledge  later  which  was 
missed  during  initial  constmcticui.  Little  additional  efimt  is 
required  to  build  training  plications  once  the  expert 
knowledge  base  is  constructed;  ifae  tqireseniation  of 
infiummion  inherent  in  the  knowledge  base  permits  automatic 
creation  of  case-oriented  lessons  for  a  full  course  curriculum. 
Fuially,  the  int^ration  with  the  Hypermedia  module  created 
the  potential  to  incorporate  knowle^e  that  is  more  general 
than  the  task-oriented  knowledge  inherent  in  the  knowledge 
base.  This  int^ration  of  hypermedia  makes  the  training 
contents  more  general  and  broadens  the  scope  of  the  tutoring 
that  can  be  offered  to  die  shxlenL 

The  major  components  of  ACQUIR£™-ITS  will  be  described 
in  the  following  section. 


3.  SYSTEM  OVERVIEW 


MACOWKE” 

ACQUIRE™  provides  an  advanced  conqmting  environment 
for  domain  experts  to  develop  and  execute  expert  system 
applications.  Fbr  developing  applicaikms,  ACX^JIRE™  has  a 
Knowledge  Acquisition  System,  and  an  Ejqjert  System  Shell. 
Developed  plications  are  executed  in  dscRun-Time  Shett. 

The  Knowle^  Acquisitioa  System  pteaenis  a  new  paradigm 
for  acquiring  knowledge.  The  main  goal  of  this  system  is  to 
ease  the  knowledge  acquisition  boldenedc  by  removing  the 
need  for  a  knowledge  engineer.  This  is  aooonqdished  by  an 
easy-to-use  interfme  and  a  structured  methodology  for 
developing  a  knowledge  base.  The  Expert  System  Shell 
conqionent  provides  easy-to-use  debugging  and  what-if 
fadbties  that  he^  develop  and  test  knowledge  bases. 
ACQUIRE™  has  been  successfully  used  to  develop  knowledge 


baset  in  Amnaimi  as  divene  as  combat  inidligence  [6],  clinka! 
neoroiisyclKdogy  [71  andequqimentinaintBiumce  [8]. 

This  section  win  discuss  the  Knowledge  Acquiation  System 
and  the  Ejqtcn  System  ShelL  This  wiU  be  followed  by  a 
diaciission  of  the  modules  that  extend  ACQUIRE™  into  the 
■Mdligent  tntnr  system  ACQUIKE™-ITS:  die  Curriculum 
Aidhor.  die  Tutor,  and  the  Hypermedia  system. 


Tbroo^  the  applicatkin  of  research  in  cognitive  psychology  a 
knowledge  acquisition  methodology  has  been  developed  that 
enables  eiqierts  to  eiqilicate  their  knowledge  in  the  fonn  of  an 
executable  knowledge  base  [3.4.6].  This  methodtdogy  is 
embodied  in  ACQUIRE™  which  fonns  the  ooroerstone  of  die 
ACQUIRE™-ITS  project  It  provides  the  means  to  build  and 
maintain  the  knowled^  bases  required  for  this  project  Thaiis. 
acquire™  elicits  nod  structures  the  knowledge  that 
subsequendy  forms  die  content  of  training  courses  that  are 
authored  and  executed  through  ACQUIRE™-ITS. 

In  order  to  acquire  knowledge  directly  from  domain  experts 
acquire™  was  based  on  a  knowledge  acquisition 
methodology  that  divided  the  knowledge  engineering  task  into 
st^  that  are  easily  and  accurately  performed.  Whoi 
completed,  these  stqis.  result  in  a  highly  structured  and 
thorough  knowledge  base  that  is  ready  for  execution. 

The  first  stqi  involves  eliciting  Objects,  the  basic  building 
blocks  of  the  knowledge  base.  Through  a  form  based  editor,  a 
set  of  objects  that  define  the  sct^  of  the  knowledge  ate 
entered.  This  siqi  enables  the  expert  to  focus  on  the  scope  of 
the  proMem  without  being  encumbered  by  issues  telatiiig  to  die 
structure  of  the  knowledge  or  the  details  of  the  rules.  Objects 
can  be  any  concrete  at  abstraa  enti^  consisting  of  a  name,  a 
valiie  set  mi  aometisaea  snapping.  A  value  set  is  a  set  of 
symbolic  values  that  ate  associated  with  the  object  For 
instance,  an  object  called  Age  Group  could  have  the  value  set 
Baby,  Child,  l^teenager.  Teenager,  Adult  and  Soiior  Citizen. 
Fiitdiermore,  every  value  set  has  a  value  called  UNKNOWN 
which  is  used  when  the  value  for  an  object  is  unknown  or 
shnply  not  available.  Mqipings  ate  us^  when  a  symbolic 
value  has  a  numeric  countennrt  to  convert  that  numeric 
quaitity  to  a  symbolic  value. 

Widi  the  basic  building  blocks  of  the  knowledge  base  defined 
the  esqpert  can  concentrate  on  the  high-level  structure  of  the 
knowledgebase.  This  second  stqi  of  building  an  ACQUIRE™ 
knowledge  base  involves  linking  the  objects  into  an  ii^uence 
aerwort  that  serves  as  a  general,  conceptual  overview  of  the 
stdutioa  qpace  that  win  subsequently  be  further  arttcuhtted. 

The  infliiCTce  network  simply  outlines  which  object  can  affect 
which  other  objects  by  linl^  them  when  knowledge  about  the 
state  of  one  can  be  hdormalive  about  the  stale  of  another.  The 
eqiett  bonds  die  infioenoe  network  by  using  a  gnphical 
mterfooe  and  browsers  of  objects.  To  aid  the  expert  in  building 
the  inflaenoe  networic  a  machine  learning  algorito  is 
moorporaled  dMt  takes  the  network  that  the  eiqiert  has 
produced  and  restructures  it  through  object  substitmion  and  by 
si«geating  dm  ad^don  of  new  objects  to  the  network.  Since 
this  a^oiMim  recommends  resBucmring  the  netwodc.imher 
dun  opecMfatg  on  its  own,  the  eapert  retains  M  control  over 
whedier  or  not  to  accept  dwrecommendatioos.  Borexample, 


die  algorithm  can  detea  where  an  intermediate  abstract  objea 
can  be  used  to  reduce  die  size  of  the  network.  Ifdieexpen 
accepts  the  leoommendaiiaos  of  the  algorithm,  the  eiqiert 
simply  names  the  new  objea  and  the  networir  is  lestructmed. 
After  the  algoridun  has  finidied  processing  die  network  and  to 
the  degree  that  die  expert  has  aocqited  its  recommendations, 
die  influence  network  will  be  smaller  and  mote  efficient 

The  third  md  final  rntyor  stqi  of  crettmg  an  A(X2U1RE™ 
knowledge  base  involves  bofo  die  packaging  of  objects  from 
the  influence  netwoik  into  rule  d^nitions.  and  die  assignment 
of  apaitero  of  objea-value  pairs  to  a  consequent  objea-value 
pair.  In  these  two  stq»  the  expert  can  focus  on  the  details 
since  the  objea  ddinitions  and  their  influence  structure  are 
already  provided. 

Rules  in  ACQUIRE™  cone  in  two  types:  the  first  being  the 
standard  production  rule  if-then  construction  md  die  second 
bang  action  tables.  A  induction  rule  describes  an  objea- 
value  pattern  such  that  if  the  premise  is  true  then  the  conclusion 
is  true. 

In  ACQUIRE™  production  rules  are  best  reserved  for  rules 
involving  aritfam^  or  mathematical  manipulations  rather  than 
for  experiential  knowledge.  Production  rules  have  a 
fundamental  weakness  in  that  they  require  the  expert  to  siqiply 
all  possible  patterns  of  objects  and  values  to  prorhice  a 
complete  kriowledge  base.  This  may  be  problematic  since 
experts  may  not  be  aware  of  all  possible  patterns  resulting  in  a 
good  chance  that  they  will  miss  obscure  patterns.  Also,  experts 
ate  rarely  accurate  at  producing  production  rules  as  there  ate 
usually  numerous  excqitions  to  any  rule  [3,4]  and  there  is  a 
tendaiicy  to  state  production  rules  at  a  for  greater  level  of 
generality  than  one  employs  in  the  practice  of 
one’s  skill. 

Action  Tables,  on  the  other  hand,  present  the  expert  with  a 
table  of  specific  objecWalue  patterns.  Action  Tables  guide  the 
expert  by  supplying  specific  object^mlues  patterns  and  all  that 
is  required  from  the  expert  is  to  supply  the  pattern  qiedfic 
conclusions. 

Action  Tables  ease  the  creation  of  rules  since  experts  ate  very 
good  at  recognizing  patterns  [3]  enabling  the  creation  of 
complex  rules  in  a  very  short  time.  A  major  benefit  of  action 
tabiM  is  tfadr  completeness.  In  production  rule  systems, 
completeness  is  ra^yattainied,  whereas  with  action  tables, 
every  objeo/value  pettein  is  described  and  the  eiqiett  must 
con^der  each  pattern  even  if  the  conclusion  is  utdmown  to  the 
expert  If  a  pattern  occurs  in  which  the  expert  does  not  know 
the  conclusion,  the  expert  can  correspond  with  other  experts  in 
the  field  and  come  to  sane  consensus  for  die  pattern.  Indus 
way  the  knowledge  base  can  ultimately  refka  whm  the  expert 
currendy  knows  as  well  as  what  die  expert  is  oqiabie  of 
knowing  with  further  experience. 

With  the  ACQUIRE™  knowledge  acquisition  paradigm,  the 
expert  leaves  the  details  of  die  rules  until  the  knowledge  base 
structure  is  fully  defined.  If  the  eiqiert  is  using  action  tables  for 
rules  then  aU  that  is  required  from  the  expen  is  to  maidi 
pattens  and  to  "fill  in  the  Uanks"  producmg  a  ooroplete  and 
accurate  knowledge  base. 
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3X2  EXPERT  SYSTEM  SHELL 

He  BaqiettSyaemSIidl  component  (rfACXyjlRE***  provides 
die  eiqmt  wiA  a  means  to  (Ung  and  r^ne  knowledge  bases. 
Hus  compGaent  provides  facilities  such  as  icscing,  stepinng 
and  what4f  anal^  (tf  the  knowledge  base  as  a  case  is  bong 
nm.  Other  aids  consist  of  detailed  iqwm.  a  graphical 
representation  <rf  the  fired-^ule  network,  and  the  abiliQr  to 
inqiea  the  contems  (rf  the  entire  knowledge  base. 

Befion  die  eaqiert  can  use  the  Eiqien  System  Shell  cose  data 
has  to  be  entered.  Cases  can  be  «>y  ml  life  sitnatioo  or  cases 
can  be  made  iq>  to  test  the  boundaries  of  the  knowledge  bases. 
Cases  consist  of  object^ralue  pairs.  Objects  within  cases  are 
those  objects  that  can  be  assi^ied  a  value  from  observation. 
Case  objects  are  usually  only  used  in  the  premise  of  rules  since 
there  is  generally  no  n^  to  set  these  objects  to  new  values. 

To  cdlect  case  data,  ACQUIRE'*' has  two  features:  the  first 
feature,  the  Case  Fonn  Editor,  is  the  mechmism  used  to  define 
the  way  case  data  is  to  be  entered;  the  second  feature,  the  Case 
Editor,  is  the  mechanism  used  to  enter  case  data.  The  Case 
Form  Editor  allows  the  expert  to  tailor  input  forms  to  suit  the 
needs  of  the  domain  as  every  domain  will  have  a  different 
itqmtrqnesentation  for  entering  the  case  data.  Ifthedatahas 
to  be  ceflected  at  run  tune  then  the  shell  collects  the  data  by 
prompting  the  user. 

The  final  aspect  of  ACQUIRE™  concerns  its  rqmrting 
capabilities.  ACQUIRE™  supplies  a  set  of  rqxxts  that  provide 
mformation  on  case  exectution.  These  rqnrts  range  from  a 
very  detailed  view  of  the  execution  to  a  sinqile  summary  of  (be 
execution.  Additionally,  users  can  build  tht^  own  customized 
iqxxts  that  can  explain  the  results  of  an  execution  in  plain 
english. 


MACQWKE°^ 

Once  a  knowledge  base  has  been  developed  and  tested  with 
ACQUIRE™,  ACQUIRE™-ITS  provides  die  tools  to  ntilizj. 
that  knowledge  base  as  the  primary  course  content  in  an 
iniellitent  training  applkatioiL  Hiis  system  makes  intelligent 
training  apidicaiions,  developed  direcdy  by  the  experts  with  the 
dornain  knowledge,  avaflsble  on  affordable  coinpniers. 

Ite  first  mqjor  module  in  ACQUIRE™-ITS,  the  Carridilirm 
Author,  lets  experts  develop  a  comae  cunricalom  composed  of 
lessons  using  a  case-study  approach.  Smdents  leam  1^  solving 
actual  or  hypothetical  cases,  packaged  into  lessons  by  the 
eaqieet  to  demonstrsie  important  concepts  and  their 
■BKRdaknai^is.  The  structure  and  comem  of  ACQUIRE™ 
knowledge  basm  guides  the  eaqiert  in  construction  (rf  the 


Tim  second  mi^  module,  the  rMor,  mantels  studem  progress 
during  case  aolutloiL  The  Tatar  atleniptB  to  niold  the  stndem's 
knoiriedliB  aoomriing  to  the  stractnn  of  the  ACQUIRE™ 
overt  knowledfB^  TUsisaooanipiiihedbyidendfyiag 
iaotnect  fate,  gtqa  in  rate  comage,  and  poor  oqaniaaiaa  of 
knowkdlB,  enpecUy  an  inoanect  pnckagiv  of  obijecta  hno 
lulea.  which  can  invwl  basic  ndaeoiioeptloiia  shorn  how 
knowledlfeikatddbesanicnaedandnaed.  The  Thtor  selects 
and  pasasmsappaopristo  eases,  flom  the  lessons  conssniciBd  by 
the  expert,  to  help  the  ilutlrm  nhriflaif  the  correct  knowledge 


as  it  B  used  m  active  problem  solving.  If  the  studem's  progress 
indicates  diatspproprateknosde^  has  not  been  acquired,  the 
Thtor  explicitly  dernonstiates  the  correct  expert  knowledge. 

ACQUIRE™-ITS  incorponies  om/fypennedia  Systan  to  that 
knoiriedge  bases  and  training  sessknrs  can  be  angmwtod  with 
bnritgronnd  textual  information,  audio,  graphics  /  shmtlations 
and  video.  Each  of  these  ACQUIRE™-ITS  conqxnents  ate 
described  in  greater  detail  in  the  following  sections. 


3A1 CTBMCULUM  AimiOR 

acquire™  produces  knowle^  bases  that  organize  the 
knowledge  at  three  differem  levds  fiom  the  geaend  to  die 
Vedfic.  At  the  most  general  levd  we  have  die  objects 
influence  network  which  can  be  grqihically  dispirit  as  the 
objectgraph.  Next,  we  have  the  rule  definitions  dut  specify 
the  objects  that  are  used  to  determine  the  values  othm 
objects.  This  level  can  be  viewed  graphically  as  the  rule  gr^rh. 
The  most  vedfic  level  of  knowledge  organization  is  die 
assignment  of  vcdfic  values  within  each  rule  ddinitioa.  This 
most  qredfic  level  of  knowledge  organization  can  be  viewed 
graphically  through  fired  rule  graphs  for  vedfic  cases.  These 
thrw  levels  of  knowledge  organization  provide  the  architecture, 
the  reasoning  paths  and  uldmaiely  the  contem  to  be  imparted 
to  the  students.  This  content,  and  its  organization  is  supplied  to 
the  Curriculum  Author.  As  a  result  the  user  of  the  Curriculum 
Author  need  not  worry  about  the  generation  of  coarse  content 
but  rather  concenuates  on  the  more  manageable  task  of 
selecting  qwdfic  avects  of  the  contentAnowledge  to  padcage 
into  lessons. 

The  Curriculum  Author  provides  tools  that  are  designed  ID 
exploit  the  architecture  m  the  knowledge  base  to  fisnlitale  rapid 
development  of  the  course  curriculum.  In  the  Curriculum 
Author  the  development  of  a  course  curriculum  is 
accomplished  through  selections  fiom  browsers,  traversing  the 
various  graphs  and  through  access  to  the  entire  knowledge  base 
and  case  b^. 

Each  cumcidiim  consists  one  or  more  lessons.  Eadi  lesson 
consists  of  one  or  more  cases  chosen  to  demonstrate  some  area 
of  eiqiettise  that  the  Curriculum  Author  user  wishes  to  import 
to  the  shident(s).  Vfithin  each  case,  objects  may  hove  one  or 
more  associated  questions. 

Questions  are  created  to  probe  the  understanding  of  the 
structure  and  content  of  the  knowledge  base.  Object  questions 
deal  with  the  static  elements  of  the  eiqieit  domain:  nameaUe 
entities,  their  value  sets  and  object  interoonnectioas.  Rule 
questions  deal  widi  inferential  aspects  of  die  knowledge-base: 
sitnatkinaltelationshvs,  and  consequential  value  aasignmenis. 
The  sysKm  supidies  a  range  of  questions  to  choose  fiom  for 
eachobjecL  OtaphioJ  as  well  as  textual  depictions  of  each 
question  are  generally  avtobMe.  The  user  can  cteato  specific 
questions  or  modify  the  system  supplied  queations.  Foreach 
question  the  user  can  create  an  asaociaied  cxplanaiioiL 

Cases  h^hHght  a  portion  of  the  knoadedge  eoteodied  in  the 
knoadedgebase.  These  cases  can  be  hteoiic  cases  that  hove 
been  aocumulaied  through  execution  of  the  knoadedge  bMe  or 
eases  created  specfficaDy  fir  tabling.  Bachcaseportntysa 
steadon  or  nnk  that  ha  oocnried  or  could  occur  bi  die  domain 
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of  knowledge.  A  case,  when  executed  through  the  expert 
knowledge  base  cat  provide  a  sihiation  or  task  specifk  vehicle 
for  ai^femiceship  learning. 

Lessons,  in  the  Curriculum  Author,  are  the  tool  used  to 
package  related  tasks,  situations  (»' content  fw  presentation  to 
the  student(s).  Lessons  can  be  as  l»oad  or  narrow  in  sct^e  as 
die  user  wants.  The  scope  of  the  lessons  is  simply  a  function 
the  cases  selected  and  the  questions  assigned  to  those  cases. 

Course  development  proceeds  quickly  as  the  Curriculum 
Author  user  dm  not  need  to  attend  to  the  devdoproent  of  the 
course  subjea  matter.  Radier  the  user  simply  selects  cases, 
selects  questions  and  assigns  those  questions  to  cases  within  the 
context  of  lessons. 


question  deals  with  the  influence  network  or  the  rule  structure, 
a  graphic  is  displayed  that  gives  the  student  a  visual  indicaiion 
of  the  information  required  from  them.  These  graphics  are 
initially  incomplete  and  are  completed  as  die  student  answers 
the  question. 

When  the  Thtor  is  invcdced  in  explore  mode,  the  student  is  able 
to  inq[>ect  any  part  of  the  expert  knowledge  base.  The 
instnictor  proddes  case  input  forms  that  the  student  can  use  to 
create  cases  that  can  be  executed.  Ihese  case  input  forms  are 
made  available  for  any  lesson  that  the  student  has  conqileted. 
Explore  mode  enables  the  studem  to  study  and  review  the 
subject  matter  contained  in  a  lesson  through  examination  of  the 
experts  reasoning  on  speciflc  cases.  The  student  benefits  &om 
access  to  the  case  input  information,  the  variety  of  case 
execution  reports,  and  from  access  to  the  expert  knowledge 
base. 


3 TUTOR 

Once  the  curriculum  has  been  completed,  the  Tiitor  is  ready  for 
use  by  the  studoiL  The  Tiitor  module  is  used  to  guide  the 
student  through  the  curriculum  following  the  case-study, 
qiprenticeship  learning,  approach.  This  module  can  be  run  in 
one  of  two  modes:  learn  or  explore.  The  student  will  generally 
run  the  Thtor  in  team  mode.  Here  the  Tutor  presents  a 
ptedeflned  curriculum  to  the  suident  in  the  order  determined 
through  the  Curriculum  Author.  The  student’s  progress  is 
tracked  and  compared  with  the  expert  knowledge  base.  Indus 
way,  the  Ttilor  can  make  intelligent  decisions  about  which  parts 
of  the  currkxilum  a  student  has  learned  and  which  parts  require 
morewcnk.  Reports  are  available  to  both  the  instructor  and  to 
the  student  detailing  where  (nogress  has  or  has  not  been  made. 
Explore  mode  enables  the  student  to  inspect  the  expert 
knowledge  base  and  to  run  cases  that  have  been  suggested  by 
the  instructor  through  the  inference  engine.  This  mode 
provides  the  studoii  with  detailed  access  to  the  expert 
reasoning  employed  in  specific  sihiations  or  tasks. 

When  the  Tutor  is  invtdted  in  leam  mode,  the  studoit  has  the 
option  of  selecting  a  qiecific  lesson  to  study  foom  or  wmking 
with  the  lesson  that  the  Tutor  selects.  Once  a  lesson  has  been 
selected,  the  cases  for  that  lesson  are  executed  through  the 
Expert  System  Shell  inference  engine.  The  student  is  (uesented 
wifo  questions  and  possible  answers  and  is  requited  to  select  an 
answer  for  each  question.  If  the  correct  answer  is  selected,  the 
session  continues  with  the  next  question. 

If  an  inconnect  answer  is  selected,  the  Tutor  decides  whether  the 
question  should  be  presented  again,  whether  a  different 
question  should  be  presented  to  probe  the  nature  of  the 
studems  miaundetstanding,  or  whether  the  answer  should  be 
supp&ed  dong  with  an  explanation.  The  decision  to  present  die 
ipiestioo  again,  10  present  an  alternate  but  related  question,  or 
to  reveal  the  answer  to  die  student  is  based  on  the  student's 
histaty  of  responses  for  the  curriculum  and  parameters  set  by 
the  Curiculum  Author  user.  Questions  that  a  student  is  having 
serious  problems  with  are  reassigned  to  subsequent  cases  so 
that  the  student’s  performance  can  be  le-evaluaied  after  die 
benefit  of  additional  caae-shidy.  Once  a  case  has  been 
completed  the  student  has  the  option  of  inspecting  it  and 
examinii^  it  more  doaely  so  at  to  better  understand  the 
reaianing  prooeas  dtat  die  expert  used. 

As  each  qnettfon  is  preieated  to  the  user,  it’s  ^  is  exannined 
todeterininewhataildiliondiafornMiontodiq^.  Whena 


The  two  modes  of  operation  in  the  Tutor  can  be  seen  as 
handling  complimentary  selects  of  the  insiruaion.  Explore 
mode  handles  initial  study  for  a  particular  lesson  and  any 
review  that  may  be  necessary.  Leam  mode  concentrates  on 
testing  the  breadth  of  the  student’s  understanding,  tmalysing 
student  difliculties  and  directing  the  student  towards  aspects  of 
the  knowledge  base  that,  once  understood,  alleviates  particular 
misunderstandings. 


3,2.3  THE  HYPERMEDIA  SYSTEM 

The  Hypermedia  system  provides  the  ACX}UIRE™-ITS  user 
with  an  environment  to  augment  the  case-study  approach  with 
text,  graphics  and  video.  This  is  accomplished  through  the 
Curriculum  Author  where  hyperbases  can  be  created  to  supply 
introductory  material,  student  instructions,  background 
information,  explanatory  information,  etc.  Each  hyperbase  is 
implemented  as  a  series  of  related  groups  of  information  that 
are  linked  together  so  that  a  student  can  easily  move  from  one 
group  of  information  to  another. 

The  Hypermedia  system,  including  it’s  various  kyperbases,  is 
made  available  to  the  Tutor  in  an  inspect  only  mode.  Through 
the  Curriculum  Author  hyperbases  can  be  linked  io  each 
curriculum,  each  lesson  and  each  case.  In  addition,  hyperbases 
can  be  linked  to  explore  mode  and  to  the  Tiitor’s  explanation 
facility.  All  hyperbases  have  a  table  of  contents  diat  enables 
the  student  to  rapidly  move  directly  to  a  speciflc  piece  of 
information  as  well  as  enabling  the  student  to  assess  what 
information  has  already  been  reviewed  and  what  informabon 
has  noL 


4,  CURRENT  STATUS  AND  FUTURE 


ism 


ACQUIRE^-ITS  is  currently  operating  in  a  prototype  stage  of 
devekqimenL  Development  has  proceeded  in  the  C 
Progrunming  Language.  UNIX  has  served  as  the  operating 
system  for  development  while  DOS  has  served  as  die  operating 
system  for  delivery  of  the  prototype.  A  character  based 
windowing  system  (Vermont  Views)  has  been  used  for  the  user 
interface  throughout  die  early  devdopment  work.  Thenser 
inteifooe  has  been  converted  to  X  windows  and  will  in  turn  be 
converted  to  Microsoft  Windows. 


At  project  onset  it  was  detennined  that  coDCuncnt  development 
of  an  industrial  apfdication  would  provide  end-user  feedback 
throng  the  entire  developnient  cycle.  MacMillan  Bloedel 
Research  and  the  Spedaltyboard  Divirion  of  MacMillan 
Bloedd's  K3  Particle  Bof^  operation  were  subcontracted  to 
develop  a  training  application.  The  qjplication  chosen  was  the 
operatkn  and  tnabitenance  the  coating  line  -  a  process  used 

to  apply  finishing  coats  to  K3  particle  board  [8].  The 
qtfdication  was  chosen  to  two  reasons:  die  process  was 
sufficieady  comidex  to  provide  a  reasonable  test  of 
ACX^jnt^-rrS  (involving  a  series  of  ovens,  senders  and  roil 
coalers  each  having  their  own  peculiar  problems);  and  training 
had  been  identified  as  a  priority  to  this  process. 

MacMillan  Bloedel  staff  built  three  knowledge  bases  in 
ACQUIRE™  while  the  early  development  work  on 
ACQUIRE™-ITS  was  unctoway.  The  experts  involved  had  no 
special  training  in  expert  system  technology.  Upon  completion 
of  these  knowledge  bases  a  prototype  of  ACQUIRE™-ITS  was 
delivered  to  MacMillim  Bloedel  and  work  commenced  on 
curriculum  development  for  the  three  knowledge  bases.  Again, 
the  experts  had  no  previous  experience  with  instructional 
technology.  Curricula  have  now  been  developed  and  executed 
to  the  sadkaction  of  the  MacMillan  Bloedel  experts.  Testing 
with  suidents  will  take  place  in  the  near  fumre. 

This  concurrent  tqiplication  development  has  driven  a  number 
of  refinements  that  will  be  carried  out  over  the  next  six  months. 
To  further  expedite  curriculum  development  facilities  are  being 
designed  to  provide  automatic  lesson  generation,  automatic 
lesson  completion  and  automatic  case  generation. 

Automatic  lesson  generation  will  analyse  the  knowledge  base 
and  suggest  lessons.  Once  the  lessons  have  been  accqxed  the 
system  will  assemble  cases  to  cover  the  subject  matter. 

Automatic  lesson  completion  will  trice  a  partially  specified 
lesson  and  complete  the  specification  with  additional  questions, 
answers  and  new  cases.  Automatic  case  generation  will 
produce  cases  that  meet  instructional  guidelines  qiecified  by 
the  Curriculum  Author  user.  The  user  will  be  able  to  tell  the 
Curriculum  Author  how  the  case  is  to  be  generated  by 
indicating  what  part  or  parts  of  the  knowledge  base  to  use.  In 
dicumstances  where  dim  is  «i  area  of  the  knowledge  base 
that  is  complex  or  riiacure,  it  may  be  instructive  to  have  the 
case  include  this  area.  These  cases  will  then  be  used  in  lessons 
and  in  explore  mode. 

TIk  role  of  the  Hypermedia  System  will  also  be  expanded. 
During  case  execution  the  hypermedia  module  will  be 
enqdoyed  to  drive  graphical  simulations.  Through  explore 
mode  this  enhancement  will  give  the  student  the  opportunity  to 
obtain  a  gnphicri  perspective  on  the  changes  that  will  occur  in 
a  given  case  when  input  values  are  changed. 


tjaacifsaoH 

A0QU1RE™-1TS  is  a  domain  independent  inielligent  tutoring 
qnieni  deaigned  to  enride  conqwier  nsen  to  develop  doll 
oriented  tcrining  oonnes  direedy.  The  choice  to  base 
ACQU1RE™-ITS  on  the  ACQUIRE™  qrstera  lealiaed  several 
cradaladvautiies.  The  knowledfeaoiiidailian  bottleneck  was 
alleviated  and  wdl  stracured  knowlei^e  bates  were  available 
to  exploiMioo  in  Brining.  Course  arihoting  was  kept 


independent  of  knowledge  base  development  consequently 
facilitating  modification  of  each.  Development  (d  the 
Hypermedia  system  along  with  the  conversion  from  character 
based  windows  to  grtqihical  based  windows  has  extended  the 
range  of  instructioiial  tools  available  to  the  Curriculum  Author 
and  the  Tutor. 

The  concurrent  application  development  work  with  MacMillan 
Bloedel  has  confirmed  that  the  tools  provide  a  practical  means 
of  utilizing  existing  industrial  personnel  to  construct  complex, 
automated  training  courses.  The  induroial  feedback  and 
experience  gained  through  devdopment  of  diis  application 
should  result  in  enhanced  intelligent  tutoring  tools  that  will 
generalize  to  a  broad  range  of  industrial  and  governmental 
training  needs. 
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SUMMARY 

/ 

In  many  real-life  application  areas  such  as  aerospace,  decisions  have  to  be 
taken  based  on  imperfect  knowledge.  If  decision  makers  are  to  be  supported 
by  con^uter  systems,  it  is  desirable  that  this  type  of  knowledge  can  be 
represented.  In  the  past  years,  new  methods  have  been  developed  to  repre¬ 
sent  various  kinds  of  imperfectness,  such  as  incompleteness,  inexactness  or 
uncertainty. 

Since  1987,  NLR  cooperates  with  the  Theoretical  Informatics  Group  of  Delft^ 
Technical  University  to  study  ways  in  which  methods  to  represent  an^,jf«fS^ 
with  uncertain  or  incomplete  information  can  be  developed  whicji.-«fe  both 
theoretically  well-founded  and  practically  applicable.  NLR ertorts  are 
directed  towards  problems  expected  in  practical  use  of  thdse  methods.  In 
1990,  we  investigated  the  applicability  of  the  Dempster-iShafer  theory.  We 
modeled  parts  of  the  initiation  and  identification  problems  in  multi-radar 
tracking.  The  application  will  be  described  in  this  paper.  It  will  be  shown 
that  the  Dempster-Shafer  theory  promises  improvements  over  the  Bayesian 
approach,  but  also  that  the  latter  currently  is  a  more  advanced  theory  than 
the  former./ 
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1 .  INTRODUCTION 

At  NLR,  the  feasibility  of  machine  intelligence  techniques  has  been  demon¬ 
strated  for  a  number  of  civil  and  military  aerospace  applications.  Human 
knowledge  in  combination  with  other  types  of  information  has  been  captured 
and  represented.  From  this  experience  we  have  concluded  that  the  methods 
used  to  reason  with  information  that  is  uncertain  or  incomplete  are  less 
adequate  for  larger  applications. 

Ideally,  we  would  want  a  method  to  fulfil  the  following  requirements: 

universality  of  representation:  all  types  of  imperfectness  can  be 
modeled 

adequacy  of  representation:  the  information  is  accurately  modeled 
verifiability  by  having  well-defined  formal  properties  such  as  sound¬ 
ness  and  completeness 
ccmqputational  efficiency 
robustness 

compliance  with  human  reasoning 
ease  of  understanding/inanipulation. 

Until  now,  no  such  methods  exist,  and  it  may  well  be  that  no  such  method 
can  ever  be  found,  because  of  the  variety  of  ways  in  which  our  information 
can  be  imperfect. 

After  an  investigation  of  existing  methods  (Ref.  1)  it  turned  out  that 
serious  effort  was  needed  to  solve  this  lack  of  good  methods  required  for 
our  applications. 

For  the  past  four  years,  NLR  has  cooperated  with  the  Theoretical  Infor¬ 
matics  Group  of  Delft  Technical  University  to  study  methods  for  reasoning 
with  uncertain  or  incofqplete  knowledge.  Main  subjects  studied  were  reaso¬ 
ning  with  fuzzy  logic  (Ref.  2),  and  non-monotonic  logics  and  certainty 
measures  that  represent  our  ignorance  about  the  world  (Ref.  3). 


This  paper  has  been  presented  at  the  AOARD  symposium  on  Machine  Intelligen¬ 
ce  for  Aerospace  Electronic  Systems,  Lisbon,  May  16,  1991. 
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Also,  the  Den^ster-Shafer  theory  was  investigated.  The  theory  was  applied 
to  two  subproblems  in  multi-sensor  fusion,  more  specifically  in  multi-radar 
tracking.  This  application  will  be  described  in  the  paper.  It  will  be  shown 
that  the  Den^ster-Shafer  theory  promises  improvements  over  the  Bayesian 
approach,  but  also  that  the  latter  currently  is  a  much  more  advanced  theory 
than  the  former. 

In  order  to  provide  the  reader  with  a  more  general  framework,  the  relation 
between  the  work  described  in  this  article  and  the  subject  of  the  confer¬ 
ence  is  described  in  section  2,  and  the  notions  used  in  reasoning  with 
incomplete  or  uncertain  information  are  presented  in  section  3,  as  well  as 
a  short  overview  of  existing  methods. 


2.  MULTI -SENSOR  FUSION 


Observation  of  the  world  with  multiple  sensors  is  becoming  more  and  more 
common  in  a  number  of  application  areas  NLR  is  involved  in,  such  as  inte¬ 
grated  modular  avionics,  command  and  control,  multi -target  tracking, 
advanced  robotics  and  air  traffic  control.  The  issues  involved  in  integrat¬ 
ing  multiple  sensors  into  the  operation  of  a  system  vary  from  low-level 
sensor  fusion  issues  to  high-level  interpretation  of  the  meaning  of  the 
aggregated  information.  Bogler  (Ref.  4)  mentions  four  requirements  for 
multi-sensor  fusion  methods  applied  to  target  identification: 

*-  Sensor  modeling:  Each  sensor  is  likely  to  be  contributing  information 
in  its  own  sensor-specific  level  of  abstraction.  The  method  must  be 
capable  of  accurately  modelling  the  information  provided  by  each  sen¬ 
sor  source . 

Fusion  and  display:  The  method  must  be  capable  of  fusing  the  informa¬ 
tion  provided,  of  computing  a  statistical  measure  for  the  resultant 
identification  quality,  and  of  accurately  displaying  the  information 
to  the  user.  In  case  of  the  target  identification,  the  displayed 
information  must  be  hierarchically  classified  in  terms  of  target 
nature  (friend/foe),  class  (fighter/bomber/missile),  and  target  type. 
Conflict  resolution:  The  method  must  be  capable  of  resolving  any 
potential  sensor  conflicts. 

Wide  range  of  applicability:  Lastly  the  design  must  be  flexible  to 
changing  scenarios,  i.e.  it  must  not  be  predicated  upon  assumptions 
about  the  operational  scenario  which,  to  a  large  degree,  is  unknown  a 
priori . * 

It  is  not  hard  to  see  that  (1)  these  requirements  also  hold  for  the  other 
application  areas  mentioned  above  and  (2)  that  the  requirements  form  a  sub¬ 
set  of  the  requirements  we  have  for  reasoning  with  incomplete  and  uncertain 
information  in  general. 

For  these  reasons,  we  consider  methods  for  reasoning  with  imperfect  infor¬ 
mation  relevant  for  many  machine  intelligence  applications  in  aerospace 
electronic  systems.  As  an  application-oriented  test  case,  we  have  studied 
Dempster-Shafer  theory  for  multi-radar  tracking. 


3.  REASONING  WITH  INCOMPLETE  OR  UNCERTAIN  INFORMATION 


Humans  are  capable  of  reasoning  when  the  available  information  is  imperf¬ 
ect.  This  is  the  case  if  the  information  has  one  or  more  of  the  following 
characteristics : 

the  information  is  incomplete;  not  everything  is  known  or  modeled 
which  pertains  to  a  problem; 

the  information  is  uncertain:  the  information  is  not  precisely  speci¬ 
fied.  It  does  not  pertain  to  the  information  set  as  a  whole,  as  does 
inconv>letenes8,  but  to  the  contents  of  the  information; 
the  information  is  inexact:  the  information  is  vaguely  or  aunbiguously 
specified.  This  notion  also  relates  to  the  contents  of  the  informat¬ 
ion. 

Various  approaches  have  been  developed  to  formalize  reasoning  with  imper¬ 
fect  information.  Some  of  them  are  purely  symbolic,  others  make  use  of 
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numbers;  some  are  close  to  formal  logic,  others  are  much  less  formalized; 
some  are  focussed  on  reasoning  with  exceptions,  others  tackle  the  problem 
of  belief  revision.  There  is  as  yet  no  consensus  as  to  what  constitutes  the 
best  method  for  dealing  with  imperfect  information. 

A  number  of  methods  will  be  mentioned  in  this  section,  to  give  the  reader 
an  impression  and  a  starting  point  for  further  reference. 


3 . 1  Early  systems 

The  two  best-known  early  numerical  systems  that  deal  with  imperfect  infor¬ 
mation  in  knowledge-based  systems  are  the  MYCIN  system  with  the  certainty 
factor  model  (Ref.  5),  and  the  PROSPECTOR  system  incorporating  a  subjective 
Bayesian  method  (Ref.  6). 

The  certainty  factor  model  is  used  by  many  rule-based  knowledge-based  syst¬ 
ems,  because  of  its  intuitive  appeal  and  its  con^utational  efficiency.  As 
many  researchers  have  explained  (e.g.  Ref.  7),  the  model  is  not  well- 
founded  from  a  mathematical  point  of  view.  Our  experience  has  learned  that 
the  model  works  reasonably  well  for  problems  in  which  the  expert  can  tune 
the  certainty  factors.  This  is  only  possible  if  the  knowledge  base  is  not 
too  complicated. 

The  subjective  Bayesian  method  will  be  described  in  section  3.3. 

Since  research  on  reasoning  with  imperfect  information  has  not  yet  yielded 
alternative  models  which  are  both  computationally  feasible  and  semantically 
clear,  the  certainty  factor  model  in  particular  still  is  in  wide-spread 
use . 


3.2  Logic-based  systems 

Logic-based  systems  based  on  propositional  logic  or  predicate  logic  are 
well  suited  to  model  information  of  which  truth  or  falsity  can  be  estab¬ 
lished  with  certainty.  These  classical  logics  cannot  deal  very  well  with 
imperfect  knowledge,  however.  As  it  remains  to  be  attractive  to  reason 
based  on  a  formal  system  with  which  properties  such  as  soundness  and  com¬ 
pleteness  can  be  proved,  a  number  of  extensions  have  been  defined. 

A  classical  logic  is  a  formal  system  composed  of: 

( i )  a  language 

(ii)  a  set  of  axioms 

(iii)  inference  rules,  and  a  description  of  the  manner  in  which  these 
axioms  and  rules  are  to  be  used  in  order  to  yield  theorems. 

Moreover,  a  semantics  is  associated  with  the  formal  system,  to  define 
meaning.  Generally,  it  is  defined  by  means  of  a  function  which  assigns  a 
truth  value  to  every  formula. 

The  classical  logic  can  be  extended  in  several  ways.  The  following  excerpt 
from  a  special  issue  of  the  International  Journal  of  Intelligent  Systems 
(Ref.  8)  shows  the  large  diversity  which  has  mainly  come  into  existence  in 
the  1980s: 

■-  The  language  is  extended,  by  introducing  predicates  (supposition- 

based  logic)  or  operators  {■possible",  "necessary"  in  modal  logic,  "I 
believe"  in  autoepistemic  logic,  operators  indicating  the  past  or  the 
future  in  temporal  logic, — ).  It  is  equally  possible  to  use  an 
implication  different  from  the  material  one  (conditional  logic),  to 
introduce  quantifiers  other  than  "For  all..."  and  "There  exists..." 
or  to  take  into  account  the  vague  character  of  predicates  (fuzzy 
logic)  or  of  quantifiers.  Finally,  uncertainty  degrees  can  be 
assigned  to  the  propositions  (possibilistic  logic  for  instance) . 

New  ^ucioma  schemata  are  added  (especially  in  the  circumscription 
approach) . 

New  notions  of  inference  are  defined,  which  permit  the  formulation  of 
answers  of  the  type  "P  is  true  in  a  certain  vision  of  the  world..." 
(in  default  logic,  we  speak  of  extensions) .  A  new  notion  of  semantics 
may  correspond  to  it  (maximal  (minimal)  model  in  the  non-monotonic 
logics,  universe  of  possible  worlds  in  modal  logic  for  exan^le) .  We 
no  longer  Impose  certain  properties  of  classical  deductive  systems, 
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such  as  inference  monotonicity  in  particular  (nonmonotonic  logics) . 

We  do  not  limit  ourselves  to  the  classical  rule  of  modus  ponens;  we 
authorize  new  inference  rules  (necessitation  rule  in  modal  logic  for 
exan^le) . * 

A  large  number  of  these  logics  are  described  and  compared  in  the  journal ; 
Turner  (Ref.  9)  also  describes  logics  and  their  relevance  to  Artificial 
Intelligence. 

Roos  (Ref.  3)  has  developed  a  new  non-raonotonic  preference  logic,  which 
combines  the  advantages  of  existing  approaches  while  avoiding  some  of  their 
disadV2uitages .  Furthermore,  a  deduction  process  in  which  reason  maintenance 
is  integrated  is  defined  for  the  logic  (see  also  section  3.5). 

Most  of  the  non-classical  logics  are  still  under  study;  only  a  small  number 
of  implementations  exist. 


3.3  Probabilistic  systems 

With  respect  to  numerical  approaches  to  reasoning  with  uncertainty,  much 
experience  is  already  available.  Especially  approaches  based  on  formal 
probability  theory  have  been  in  use  much  longer  than  any  other  of  the 
approaches  described  in  this  paper. 

A  hectic  debate  is  still  going  on,  however,  in  the  philosophical,  mathemat¬ 
ical  and  artificial  intelligence  communities  with  respect  to  the  meaning  of 
the  word  probability. 

Since  the  turn  of  the  century,  three  views  have  dominated  (Ref.  10): 

Objectivistic  or  frequentistic:  Probability  measures  the  ratio  of 
occurrences  to  observations  for  a  proposition,  in  the  long  run. 
Personal istic,  subjectivistic,  or  judgmental:  Probability  measures 
the  confidence  that  an  individual  has  a)30ut  a  particular 
proposition's  truth. 

Necessary  or  logical:  Probability  measures  the  extent  to  which  one 
set  of  propositions,  out  of  logical  necessity  and  apart  from  human 
opinion,  confirms  the  truth  of  another.  Probability  thus  measures 
inferential  soundness  or  provability.  Proponents  generally  view  this 
view  as  an  extension  of  logic. 

Pearl,  one  of  the  proponents  of  reasoning  with  probabilities  (instead  of 
logics,  other  non-numerical  or  heuristic  approaches),  gives  an  excellent 
overview  of  the  development  of  probability  theory  (Ref.  11).  The  following 
is  mainly  based  on  his  description. 

The  Italian  mathematician  Cardano  (1501-1576)  is  believed  to  be  the  first 
to  have  formulated  the  notion  of  probability  in  gambling  in  terms  of  the 
number  of  distinguishable  ways  that  events  may  occur.  His  "objective"  view 
of  prolaability  developed  into  a  mathematical  theory  of  combinatorics,  due 
to  Fermat,  Pascal,  Huygens,  Bernoulli,  De  Moivre  and  Laplace;  it  was 
Poisson  who  defined  probability  as  a  limit  of  a  long-run  relative  freq¬ 
uency.  Borel  and  Kolmogorov  developed  the  modern  axiomatic  foundations  of 
mathematical  probability,  in  which  the  concept  of  random  experiment  plays  a 
crucial  role:  of  such  an  experiment,  the  outcome  cannot  be  predicted  with 
certainty,  but  the  experiment  is  of  such  a  nature  that  the  collection  of 
every  possible  outcome  can  be  described  prior  to  its  performance;  furtherm¬ 
ore,  the  experiment  can  be  repeated  under  the  same  conditions. 

In  parallel  to  these  mathematical  developments,  an  alternative  view  of 
probability  c^une  into  being  with  Bernoulli's  suggestion  that  probability  is 
a  degree  of  confidence  that  an  individual  attaches  to  an  uncertain  event. 
This  concept,  aided  by  Bayes'  rule  (Ref.  12)  was  evident  in  the  writings  of 
Laplace  and  Oe  Morgan  and  later  in  the  work  of  Keynes  (Ref.  13)  and 
Jeffreys  (Ref.  14).  It  was  not  until  the  1950s  with  the  development  of 
statistical  decision  theory,  that  Bayesian  methods  gained  their  current 
mcxnentum.  'The  defining  attributes  of  the  Bayesian  school  are  (1)  willing¬ 
ness  to  accept  subjective  opinions  as  an  expedient  substitute  of  raw  data 
and  (2)  adherence  to  Bayes  condltionalization  as  the  primary  mechanism  for 
updating  belief  in  light  of  new  information. 
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The  heart  of  the  Bayesian  techniques  lies  in  the  celebrated  inversion  form¬ 
ula: 


which  states  that  the  belief  we  accord  a  hypothesis  H  upon  obtaining  evi¬ 
dence  e  can  be  computed  by  multiplying  our  previous  belief  P(H)  by  the 
likelihood  P(e|H)  that  e  will  materialize  if  H  is  true.  P(H|e)  is  sometimes 
called  the  posterior  probability,  and  P(H)  is  called  the  prior  probability. 
Whereas  a  formal  mathematician  might  dismiss  this  equation  as  a  tautology 
stemming  from  the  definition  of  conditional  probabilities,  the  Bayesian 
subjectivist  regards  the  equation  as  a  normative  rule  for  updating  beliefs 
in  response  to  evidence.  The  conditional  probabilities  then  are  primitives 
of  the  language  and  faithful  translations  of  the  English  expression 
" . . . ,  given  that  I  know  A. * 

PROSPECTOR  is  one  of  the  few  expert  systems  that  relies  on  Bayesian  deci¬ 
sion  theory  and  Bayes'  rule.  Instead  of  using  the  prior  and  conditional 
probabilities  directly,  it  uses  odds- likelihood  functions.  The  advantage 
that  likelihood  methods  have  over  prior  and  conditional  probabilities  is 
that  people  feel  far  more  comfortable  providing  likelihood  ratios.  Since 
the  original  prior  and  conditional  probabilities  can  be  recovered  from  the 
likelihood  ratios,  this  approach  can  use  Bayes'  rule  to  propagate  evidence. 
To  use  the  PROSPECTOR  approach,  conditional  independence  of  evidence  is 
required  under  both  a  hypothesis  and  its  negation.  Since  these  assumptions 
are  rarely  satisfied,  useability  of  the  approach  is  severely  restricted. 

The  Dempster-Shafer  theory  is  another  example  of  a  probabilistic  approach. 
Because  of  its  importance  to  this  article,  it  is  separately  described  in 
section  4. 


3 . 4  Endorsements 


A  qualitative  approach  to  reasoning  with  imperfect  information  is  the  the¬ 
ory  of  endorsements  (Ref.  15). 

In  most  real  world  settings,  the  "strength  of  evidence*  actually  is  a  sum¬ 
mary  of  several  factors.  Numerical  approaches  summarize  supporting  and 
opposing  evidence.  Cohen  argues  that  an  intelligent  reasoner  usually  dis¬ 
criminates  among  these  factors.  The  theory  of  endorsements  is  centred 
around  the  idea  of  dealing  with  reasons  for  believing  or  disbelieving  a 
hypothesis.  By  making  explicit  the  knowledge  about  uncertainty  and  evid¬ 
ence,  endorsements  show  how  to  reason  with  the  knowledge  directly. 


3 . 5  Reason  maintenance  systems 

The  same  ideas  which  have  led  to  the  endorsements  approach  can  be  found  in 
Truth  Maintenance  Systems,  or  more  generally,  reason  maintenance  systems. 
The  idea  behind  these  systems  is  that  justifications  or  assumptions  for 
reasoning  steps  shall  be  kept,  separate  from  the  reasoning  system.  Reason 
maintenance  is  especially  important  in  the  case  of  non-roonotonic  reasoning. 
If  a  contradiction  occurs  between  consequences  of  decisions  taken  in  an 
earlier  stage  and  consequences  derivable  from  new  information  as  it  comes 
available,  the  reasoning  system  can  consult  the  reason  maintenance  system 
to  provide  ways  by  which  the  system  can  return  to  a  consistent  state.  For 
this  reason,  these  systems  are  sometimes  called  belief  revision  systems. 
Well-known  reason  maintenance  systems  are  the  Truth  Maintenance  System  dev¬ 
eloped  by  Doyle  (Ref.  16)  and  the  Assumption-lsased  Truth  Maintenance  System 
of  de  Kleer  (Refs.  17,18,19). 

In  general,  in^lementation  of  these  systems  is  not  easy;  memory  and  perfor¬ 
mance  problems  are  not  easy  to  avoid. 
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3.6  Fuzzy  systems  and  possibility  theory 

Fuzzy  reasoning  concerns  are  distinct  from  those  of  the  formalisms  con¬ 
sidered  sofar.  It  deals  with  vague  notions  in  information  people  use,  such 
as  "Visibility  is  rather  low  today*.  Fuzzy  logic  can  be  considered  as  a 
synthesis  of  fuzzy  set  theory  and  mathematical  logic.  It  uses  fuzzy  sets 
instead  of  propositions  and  predicates.  These  fuzzy  sets  are  used  to  denote 
linguistic  notions.  They  are  different  because  they  have  implicit  meaning. 
Usually,  this  meaning  is  not  taken  into  account  explicitly,  because  not 
doing  so  makes  it  easy  to  transform  fuzzy  logic  into  a  kind  of  multivalued 
logic.  Hellendoorn  has  proposed  an  alternative  approach  using  shifted 
hedges,  in  which  the  meaning  of  the  fuzzy  sets  is  taken  into  account 
(Ref.  2) . 

Since  the  publication  of  Zadeh's  paper  ‘Fuzzy  sets  as  a  basis  for  a  Theory 
of  Possibility*  (Ref.  20),  possibility  theory  has  become  an  important 
keyword  in  fuzzy  set  theory.  An  important  thesis  in  that  paper  is  that  when 
one's  main  concern  is  with  the  meaning  of  the  information  rather  than  with 
its  measure,  the  proper  framework  is  possibilistic  rather  than  probabil¬ 
istic  in  nature.  In  this  way  a  fuzzy  variable  (concerning  a  meaning)  is 
associated  with  a  possibility  distribution  in  much  the  same  way  as  a  random 
variable  (concerning  a  measure)  is  associated  with  a  probability  distribu¬ 
tion  (Ref.  2) . 

First  implementations  in  this  category  exist  primarily  for  fuzzy  control 
applications . 


4.  THE  DEMPSTER -SHAFER  THEORY 


In  his  work  on  statistical  inference  (Ref.  21,22),  Dempster  criticised 
Bayesian  inference  for  its  insistence  that  we  assess  a  subjective  prior 
distribution,  even  if  we  do  not  know  much  about  it.  He  proposed  an  alter¬ 
native  approach  which  avoids  the  need  for  these  prior  distributions.  A  con¬ 
sequence  of  this  approach  is  that  the  notion  of  point  probability  is 
replaced  by  upper  and  lower  probabilities.  Shafer  has  built  a  theory  of 
belief  functions  based  on  the  earlier  work  of  Dempster.  The  idea  behind  the 
Dempster-Shafer  theory  of  belief  functions  is  described  in  a  paper  by 
Shafer  (Ref.  23): 

*  The  theory  of  belief  functions  provides  two  basic  tools  to  help  us  make 
probability  judgments:  a  metaphor  that  can  help  us  organize  probability 
judgments  based  on  a  single  item  of  evidence,  and  a  formal  rule  for  combin¬ 
ing  probability  judgments  based  on  distinct  and  independent  items  of  evid¬ 
ence  . 

Here  is  the  metaphor  for  organizing  our  probability  judgments.  We  think  of 
our  belief  (or  our  "probability*,  if  you  will)  as  a  whole  and  imagine  com¬ 
mitting  parts  of  that  whole  ("probability  masses")  to  various  propositions. 
The  ^unount  we  commit  represents  a  judgment  as  to  the  strength  of  the  evi¬ 
dence  that  specifically  favours  that  proposition.  It  is  not  required  that 
belief  not  coiranitted  to  a  given  proposition  should  be  committed  to  its 
negation,  nor  that  belief  committed  to  a  given  proposition  should  be  com¬ 
mitted  more  specifically." 

Shafer  has  worked  out  this  metaphor  into  a  mathematical  theory  of  evidence 
(Ref.  24) .  The  theory  is  most  easily  introduced  in  the  case  where  we  are 
concerned  with  the  true  value  of  one  quantity.  If  we  denote  the  quantity  by 
6,  and  the  set  of  its  possible  values  by  O,  then  the  propositions  of  inter¬ 
est  are  precisely  those  of  the  form  'The  true  value  of  8  is  in  T* ,  where  T 
is  a  subset  of  6.  Thus  the  propositions  of  interest  are  in  a  one-to-one 
correspondence  with  the  subsets  of  6,  and  the  set  of  all  propositions  of 
interest  corresponds  to  the  set  of  all  subsets  of  6,  which  is  denoted  by 
the  symbol  2*.  The  same  formalism  can  be  extended  to  situations  where  0  is 
an  arbitrary  par2uneter  that  takes  possibly  non-numerical  values.  Shafer 
calls  the  set  O  the  frame  of  dlseeniMDt .  In  order  to  work  out  the  intu¬ 
itive  picture  wherein  a  portion  of  belief  can  be  committed  to  a  proposition 
but  need  not  be  committed  either  to  it  or  its  negation,  a  portion  of  belief 
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committed  to  one  proposition  is  therein  committed  to  any  other  proposition 
it  implies.  In  terms  of  a  frame  of  discernment,  this  means  that  a  portion 
of  belief  committed  to  one  subset  is  also  committed  to  any  subset  contain¬ 
ing  it.  So  of  the  total  belief  committed  to  a  given  subset  A  of  a  frame  &, 
some  may  also  be  committed  to  one  or  more  proper  subsets  of  A,  while  the 
rest  will  be  committed  exactly  to  A,  i.e.  to  A  and  to  no  smaller  subset. 

In  the  following  sections,  the  mathematical  formulation  of  the  Dempster- 
Shafer  theory  is  presented.  In  section  4.1,  belief  functions  are  defined; 
in  section  4.2,  Dempster's  rule  for  combination  of  beliefs  is  presented. 


4.1  Belief  functions 


If  0  is  a  frame  of  discernment,  then  a  function  m:  2*  -•  [0,1]  is  called  a 
basic  probability  assignment  whenever 

(1)  m(e)=0 

and 

(2)  ^  m(A)*l 

The  quantity  m(A)  is  called  A's  basic  probability  number,  and  is  understood 
to  be  the  measure  of  belief  that  is  committed  exactly  to  A.  To  obtain  the 
measure  of  total  belief  in  A,  one  must  add  to  m(A)  the  quantities  m{B)  for 
all  proper  subsets  B  of  A: 


Bel  (A)* 

A  function  Bel;  2*  [0,1]  is  called  a  belief  function  over  0  if  it  is 

given  by  this  formula  for  some  basic  probability  assignm«»nt  m:  2*  [0,1]. 


Remark . 

The  class  of  belief  functions  can  be  characterized  without  reference  to 
basic  probability  assignments: 

If  0  is  a  freune  of  discernment,  then  a  function  Bel:  2*  — )-[0,l]  is  a  belief 
function  if  and  only  if  it  satisfies  the  following  conditions: 

(1)  Bel(0)  =  0 

(2)  Bel(0)  =  1 

(3)  For  all  n>0  and  for  each  collection  of  subsets  Ai,..,A„  of  0: 


BeKAjVA,  ..  Va„)  i  T  (-l)‘l^l-»>Bel(nAi) 

Icuf.n) 

J*9 


Furthermore,  the  basic  probability  assignment  that  produces  a  given  belief 
function  is  unique  and  can  be  recovered  from  the  belief  function: 

Suppose  Bel:  2®  -*  [0,1]  is  the  belief  function  given  by  the  basic 
probability  assignment  m:  2®  -»  [0,1].  Then, 

m(A)  -  g  (-l)l*-"lBel(B) 
for  all  A  c  0. 


End  of  remark 
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Bel (A)  does  not  reflect  to  what  extent  one  doubts  A  -i.e.  to  what  extent 
one  believes  its  negation  A.  A  fuller  description  consists  of  the  degree  of 
belief  Bel (A)  together  with  the  degree  of  doubt: 

Dou(A)  =  Bel(A) . 

The  quantity 

P*(A)  =  l-Dou(A) 

expresses  the  extent  to  which  one  fails  to  doubt  A  i.e.  the  extent  to 
which  one  finds  A  credible  or  plausible.  Shafer  calls  this  function  the 
upper  probability  of  A. 

The  significance  of  the  belief  and  plausibility  measures  is  based  on  the 
fact  that  it  can  be  shown  (Ref.  21)  that  they  provide  an  upper  and  a  lower 
bound  on  the  probability  of  B,  that  is, 

Bel(B)  <  Prob(B)  S  Pl(B). 

Since  in  a  probabilistic  environment  the  best  information  we  can  have  is 
knowledge  of  the  probability  of  each  set,  the  smaller  Pl(B)-Bel(B)  the  more 
we  know  about  the  situation. 


4.2  Dempster's  rule  of  combination 

Combination  of  distinct  bodies  of  belief  is  achieved  via  in  Dempster's  rule 
of  combination.  Shafer  writes  (Ref.  24):  “Given  several  belief  functions 
over  the  same  frame  of  discernment  but  based  on  distinct  bodies  of  evid¬ 
ence,  Dempster's  rule  of  combination  enables  us  to  compute  their  orthogonal 
sum,  a  new  belief  function  based  on  the  combined  evidence.  * 

In  mathematical  form,  the  rule  is  stated  as  follows: 

Let  Bel  and  Bel'  be  belief  functions  induced  by  the  basic  probability 
assignments  m  and  m',  respectively.  If  E  {m(Ai)  .m' (Bj)  |  Aj  n  B^  ^  0)  =  0, 
then  Bel  and  Bel'  are  called  not  combinable.  Otherwise,  Bel  ©  Bel',  the 
combination  of  Bel  and  Bel'  by  Dempster's  rule,  is  the  belief  function 
induced  by  m  ®  m' ,  where 


m  0  m'(A) 


£  m(AJ  .m'(BJ 

Atre)-* _ _ 

E  m(A,)  .m'(B,) 


if  A  ^  0  and  m  ®  m'  (0)=  0. 


4.3  Evidential  reasoning  with  Dempster-Shafer  theory 

There  are  two  major  ways  to  think  about  the  Dempster-Shafer  theory.  The 
first  one  described  above  is  in  terms  of  subjective  pro)5abilities,  the  sec¬ 
ond  one  is  in  terms  of  evidence.  To  this  end,  Shafer  introduces  simple  sup¬ 
port  functions  to  denote  bodies  of  evidence  whose  effect  is  to  support  the 
subset  A  to  a  degree  s: 

A  belief  function  Bel:  2^  -*  [0,1]  is  called  a  simple  support  function  if 
there  exists  a  non-empty  subset  A  of  9  and  a  number  s,  0  S  s  S  1,  such  that 

0  if  B  does  not  contain  A 
Bel  (B)  =  s  if  B  contains  A  but  B^9 
1  if  B=9. 

'There  are  other  types  of  support  functions,  which  will  not  be  discussed 
here.  'The  notion  of  support  functions  is  important,  because  they  seem  to 
constitute  the  subclass  of  belief  functions  appropriate  for  the  representa¬ 
tion  of  evidence. 
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To  represent  complete  ignorance,  i.e.  we  do  not  have  any  evidence  at  all, 
we  commit  all  our  belief  to  the  frame  of  discernment  -  that  is,  we  assign 
m(6)=l,  and  m(A)=0  for  every  proper  subset  of  0. 

If  we  do  know  something  more,  an  adequate  summary  of  the  impact  of  evidence 
on  a  particular  proposition  A  must  include  at  least  two  items  of  informat¬ 
ion:  a  report  on  how  well  A  is  supported  and  a  report  on  how  well  its  nega¬ 
tion  A  is  supported.  Since  a  proposition  is  plausible  in  light  of  the  evi¬ 
dence  to  the  extent  that  evidence  does  not  support  its  negation,  these  two 
items  of  information  can  be  conveyed  by  reporting  the  proposition's  degree 
of  support,  S(A),  together  with  its  degree  of  plausibility: 

PI  (A)  =  1  -  S(A) 

The  relations  between  the  subjective  terms  and  the  evidential  terms  is 
given  in  table  1  (Ref.  24) 


Table  1. 

Subjective  versus  evidential  vocabulary  for  Dempster-Shafer  theory 


1  Subjective  vocabulary 

Evidential  vocabulary 

1 

Degree  of  belief 

Bel (A) 

Degree 

of 

support 

S(A) 

Degree  of  doubt 

Dou(A)=Bel(A) 

Degree 

of 

dubiety 

Dub(A)=S(A)  1 

Upper  probability 

P*(A)=l-Bel(A) 

Degree 

of 

plausibility 

P1(A)=1-S(A)  j 

5.  NLR'S  BAYESIAN  MULTI-SENSOR  TRACKING  SYSTEM 

At  the  National  Aerospace  Laboratory  NLR,  a  multi-sensor  tracking  system 
has  been  developed  for  both  civil  and  military  applications.  The  task  of 
the  tracking  system  is  to  provide  state  information  (tracks)  about  flying 
objects  in  the  area  under  consideration.  This  area  is  covered  by  one  or 
more  sensors,  possibly  of  different  type,  which  provide  data  about  the 
environment  to  the  tracking  system.  The  data  are  received  by  the  most 
important  module  of  the  tracking  system,  the  track  continuation  module, 
which  updates  its  tracks  based  on  these  data.  Data  which  can  be  associated 
with  existing  tracks  are  kept;  all  other  measurements  are  handed  over  to 
the  track  initiation  module.  Each  sensor  system  has  its  own  track  initi¬ 
ation  module  responsible  for  initiation  of  tracks  for  flying  objects  in  its 
area  of  observation.  Once  a  track  has  been  initiated,  it  is  immediately 
handed  over  to  the  continuation  system. 

Compared  to  a-p,  Kalman-based  and  state  of  the  art  tracking  systems,  the 
NLR  tracking  system  provides  better  track  continuity,  more  accurate  expec¬ 
tations  of  position  and  velocity  (especially  in  case  of  sudden  manoeuvres) , 
a  lower  sensitivity  for  measurement  errors,  more  con¥>lete  additional  infor¬ 
mation  in  the  form  of  probabilities  of  modes  of  flight  (turns,  acceler¬ 
ations  and  straight  modes)  and  consistent  estimates  of  its  own  accuracy 
(Ref.  25)  The  computational  power  required  is  far  less  than  for  other, 
recently  developed  high-performance  algorithms  for  tracking  manoeuvring 
aircraft  (Ref.  26).  It  has  been  demonstrated  that  the  tracking  system  will 
run  in  real  time  on  presently  available  multi -processor  systems  (Ref.  27) . 

In  many  parts  of  the  tracking  system,  Bayesian  methods  have  proved  to  be 
effective.  The  track  continuation  module  for  instance  consists  of  a  combi¬ 
nation  of  those  approximate  Bayesian  methods  that  proved  to  be  the  most 
efficient  for  the  main  problems  of  track  continuation:  Extended  Kalman  fil¬ 
tering  for  non-linear  dynamics.  Probabilistic  Data  Association  for 
unassociated  measurements  and  Interacting  Multiple-Model  filtering  for  sud¬ 
den  manoeuvres. 
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Other  parts  of  the  tracking  system  offer  opportunities  to  evaluate  methods 
initially  representing  ignorance,  and  later  representing  new  information  as 
it  becomes  available.  The  following  aspects  of  the  multi-sensor  tracking 
problem  were  interesting  from  an  uncertainty/ incompleteness  point  of  view: 

reflection 

assignment  of  A  codes 
track  initiation 
track  association 
object  identification. 

Two  of  these  were  chosen  to  gain  experience  with  the  Dempster-Shafer 
approach,  viz.  the  identification  problem  and  the  track  initiation  problem. 
These  will  be  described  in  more  detail  in  the  next  section. 

Other  methods  for  reasoning  with  in^erfect  information  possibly  offer  bet¬ 
ter  solutions  for  the  other  aspects  mentioned  above.  In  particular,  non¬ 
monotonic  reasoning  seems  to  be  an  important  area  to  be  investigated. 


6.  DEMPSTER-SHAFER  THEORY  FOR  MULTI -RADAR  TRACKING 


The  track  initiation  problem  and  the  identification  problem  have  been 
chosen  from  an  initial  list  of  possible  additions  to  the  multi-sensor 
tracking  system.  These  fall  into  three  categories: 

solutions  for  problems  not  already  captured  in  some  way  by  the  track¬ 
ing  system; 

solutions  to  problems  which  have  been  modeled  in  the  tracking  system 
using  Bayesian  methods,  where  Dempster-Shafer  theory  might  reduce 
complexity; 

solutions  to  provide  increased  accuracy. 

The  identification  problem  falls  into  the  first  category,  the  initiation 
problem  is  an  element  of  the  second  category. 


6.1  Track  initiation 


The  track  initiation  problem  deals  with  the  initiation  of  tracks  in  the 
presence  of  more  than  one  flying  object.  After  assessment  of  a  number  of 
possible  situations  (Ref.  28).  the  following  setup  has  been  chosen: 

A  number  of  n  radars,  located  at  physically  different  locations  Pj,  provide 
measurements  of  an  object  O. 

To  model  this  problem  in  the  Dempster-Shafer  way,  three  steps  must  be 
taken : 

reduction  of  measurements  at  approximately  the  same  time  to  exactly 

the  same  instant  in  time; 

assignment  of  belief  to  the  measurements; 

combination  of  the  belief  functions  of  all  measurements. 

Our  modelling  of  the  initiation  problem  has  concentrated  on  the  definition 
of  a  basic  probability  assignment  in  such  a  way  that  combination  of  belief 
could  be  performed  in  a  natural  way. 

As  the  first  step  does  not  detract  from  our  model,  we  will  skip  it  here  for 
simplicity  purposes.  The  problem  is  then  formulated  as  follows: 

Suppose  that  a  group  of  q  radars  is  located  at  p,  and  a  group  of  r-g  at 
location  P2.  We  assume  that  all  radars  provide  measurements  at  times  t^. 

At  time  t),  r  measurements  have  been  done  (each  radar  has  provided  one 
measurement).  The  situation  is  depicted  in  figure  1.  With  x,  we  denote  the 
measurements  radars  at  location  p,,  and  with  the  measurements  from 
radars  at  location  pj.  The  measurements  of  radar  i  are  denoted  by  mi. 
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Figure  1.  Location  of  radars 

Direct  combination  of  measurements  in  the  standard  Dempster-Shafer  way 
would  give: 

0  if  m^  ^  mj,  i  e  {1,  ...  q)  and  j  e{q+l,  ...  ,  r) 

m^  if  m^  =  mj,  i  e  {1,  q)  and  j  6  {q+1,  ...  ,  r)  . 

The  situation  mj^  n  mj  will  practically  never  occur,  as  that  would  mean  that 
the  measurement  from  radar  i  is  identical  to  the  measurement  of  radar  j . 
Therefore,  the  straight  forward  interpretation  does  not  provide  a  realistic 
model . 

To  solve  this,  we  construct  for  each  measurement  i  an  area  around  the 
measurement.  The  idea  is  that  we  now  will  assign  belief  to  the  idea  that 
given  the  measurement  i,  the  object  is  somewhere  within  the  area. 

We  take  the  area  to  be  a  sphere  bj  with  centre  m^  and  radius  rj^,  and  we 
will  use  four  radars:  two  identical  ones  at  location  p^  and  two  identical 
ones  at  location  P2- 

Suppose  that  at  a  certain  instant  in  time,  the  radars  provide  the  following 
measurements  (>,  x  are  the  measurements  from  the  radars  at  locations  pj^  and 
Pj  respectively)  :  ^ 

Figure  2.  Measurements  and  spheres  for  all  four  radars 


To  assign  belief  functions,  we  first  look  at  the  measurements  from  the 


Figure  3.  Measurements  and  spheres  for  the  two  radars  at  location  pi. 


T 
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Four  subareas  can  be  distinguished,  viz.: 

d]  :  the  sphere  around  the  first  measurement 
d,  :  the  intersection  between  the  two  spheres 
d,  :  the  sphere  around  the  second  measurement . 
d^  :  the  range  of  the  radars  outside  the  spheres. 

To  these  areas,  a  basic  probability  assignment  (bpa)  will  be  made.  This 
assignment  will  in  practice  be  dependent  on  the  accuracy  of  the  radar,  the 
weather  conditions,  the  accuracy  of  the  measurement  itself,  statistics, 
etc.  We  abstract  fr<xn  the  precise  form  of  the  bpa. 

Suppose  we  assign  some  belief  to  the  idea  that  the  object  is  located  within 
the  sphere  bj  and  that  we  assign  the  rest  of  our  belief  to  all  points  with¬ 
in  the  range  of  the  radar.  We  then  have: 

m(bi)  =  Yi 

m(©)  =  l-yi  ,  with  0  all  possible  spheres  with  centre  within  range 

Rp,  of  radar  i. 

As  can  be  seen  from  the  definition  of  a  simple  support  function  (SSF)  in 
section  4.3,  the  belief  function  Bel  defined  by  this  bpa  is  a  simple  sup¬ 
port  function. 

Combination  of  the  two  SSFs  is  depicted  in  figure  4: 


0: 

b. 


Figure  4.  Combination  of  two  SSFs  into  the  belief  function  SSFPl . 


d, 

© 

b,  r»  bj 

d, 

b,  ©1 


m(cli)  =  Yi-  (I-Y2) 

=  YfYi 

m(dj)  =  (l-yi).y2 
m(©,)  =  (1-yi) .  (1-yj) 


For  the  radars  located  at  p,,  we  get  (see  figure  2)  : 

n>(b,)  =  yj 
m(©2)  =  1-yj 
in(b«)  =  y4 
ro(©j)  =  l-y4 


02 


b« 


b,  ©2 

Figure  5.  Combination  of  two  SSFs  into  the  belief  function  SSFP2. 


With  normalization  constant  K  s  1  /  (l~y).y4) : 

»{ci«)  *  yj-  (i-y4)  -K 

m(d,)  «  {l-yj).y4-K 

ro(©2)  ■  (1-yi)  •  (i-y^) 

Combination  of  SSFPl  with  SSFP2  results  in: 


d4 

© 

b,  n  b4  =  0 

d. 

1 


SSFP2 
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e, 

ds 


z 

Z 

Z 

Rpl  o  Rp2 

0 

0 

0 

Y 

bj  n  bi 

bj  r*  bj  o  bj 

bj  n  bj 

Y 

d, 

d. 

d, 

01 

SSFPl 


Figure  6.  Combination  of  SSFPl  and  SSFP2  into  final  belief  function 


di  i  f  m^  €  Rpi  and  i  e  {3,4} 

Y  =  0,  n  dj  = 

0  elsewhere. 


d,  i  f  mj  €  Rpj  and  i  e  (1,2,3) 

Z  =  0,  n  di  = 

0  elsewhere. 

In  this  way  we  can  again  construct  the  single  support  function  from  the 
diagr^un  as  we  did  before . 


Remark.  The  combination  of  belief  functions,  which  we  in  the  example  per¬ 
formed  first  per  location,  can  be  done  in  arbitrary  order,  as  associativity 
as  guaranteed  by  Dempster's  combination  rule. 

In  ref.  27,  more  can  be  found  on  the  modelling  of  the  initiation  problem. 

We  will  now  turn  to  the  second  problem. 


6.2  The  identification  problem 

The  objective  of  identification  is  to  generate  a  classification  of  objects, 
based  on  track  information  generated  by  the  Bayesian  multi-sensor  tracking 
system.  The  objects  present  in  the  area  under  consideration  must  be  clas¬ 
sified  in  accordance  with  the  measurements,  into  one  of  a  number  of 
classes.  As  an  exeunple,  we  take: 

the  object  is  a  bird  (bi) 

the  object  is  a  non-flying  object  (nfo) 

the  object  is  a  transport  aircraft  (ta) 

the  object  is  another,  non-transport  aircraft  (nta) 

the  object  is  a  unidentified  object  due  to  false  measurements  (fm) . 

Together,  the  classes  form  the  fr2une  of  discernment  0. 


At  each  point  in  time,  the  following  statements  shall  be  made  about  an 
object  in  order  to  be  able  to  classify  it: 


1.  The  object  is  (1)  moving  with  constant  speed  in  a  constant  direction, 
(2)  accelerating  in  constant  direction  or  (3)  turning. 

2.  The  position  of  the  object  is  inside  vs.  outside  the  range  of  the 
sensors . 


3.  The  object  is  at  a  certain  altitude,  or  is  climbing/descending. 


4. 


The 

vlt 

v2! 

v3: 

v4: 


object  belongs  to  one  of  four  speed  categories: 
the  velocity  is  0  m/s. 

the  velocity  is  in  the  interval  (0  m/s,  5  m/s] 
the  velocity  is  in  the  interval  (S  m/s,  300  m/s) 
the  velocity  is  larger  than  300  m/s. 
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These  four  items  from  components  of  a  measurement. 

If  the  object  is  moving  with  constant  speed  in  a  constant  direction,  than 
this  can  be  seen  as  evidence  for  bi,  ta  and  nta.  This  is  also  the  case  if 
the  object  is  turning. 

If  the  position  of  the  object  is  outside  the  range  of  the  sensors,  than 
this  can  be  seen  as  evidence  for  fm.  If  the  position  falls  inside  the 
range,  than  evidence  for  bi,  nfo,  ta  and  nta. 

If  the  object  remains  at  altitude,  evidence  is  accumulated  for  nfo,  ta,  nta 
and  bi.  If  the  object  varies  in  altitude  in  a  small  time  interval,  evidence 
is  accumulated  for  ta,  nta  and  bi. 

The  speed  category  vl  forms  evidence  for  nfo,  nta  (e.g.  helicopters)  and 
bi .  Speed  category  v2  forms  evidence  for  nta  and  bi,  v3  for  nta  and  ta,  and 
v4  for  nta. 


The  easiest  way  to  proceed  is  to  define  a  belief  function  for  each 
measurement,  and  then  combine  them  using  Dempster's  rule  of  combination. 
Disadvantage  of  this  method  is  that  no  use  is  made  of  dependency  between 
measurements  at  different  time  intervals.  A  passenger  aircraft  for  instance 
will  make  few  turns,  go  to  an  economical  altitude  and  stay  there  if  it  can. 
The  components  2  and  3  of  the  measurement  can  be  left  out  without  deterio¬ 
rating  the  model  too  much. 

It  would  be  better  to  construct  belief  functions  that  use  as  many 
measurements  as  possible. 

To  this  end,  we  define  a  time  interval  T  in  which  several  measurements  take 
place.  Per  component,  a  belief  function  is  constructed.  Ultimately,  these 
belief  functions  are  cc»nbined  into  an  evaluation  function. 


Building  these  belief  functions  is  a  matter  of  constructing  functions  that 
comply  with  our  intuition.  We  know  of  no  standard  method  to  translate  this 
type  of  knowledge  into  belief  functions.  For  every  problem  that  is  tackled 
with  the  Dempster-Shafer  theory  one  will  have  to  use  one's  imagination. 

For  the  identification  problem,  we  have  constructed  belief  functions  for 
each  of  the  components  of  a  measurement.  Each  knowledge  element  was  trans¬ 
lated  into  a  numerical  formula.  For  instance,  if  we  the  number  of  instances 
in  which  the  object  is  flying  at  constant  speed  in  a  constant  direction, 
our  belief  in  the  object  being  a  transport  aircraft  increases.  To  reflect 
this,  we  have  chosen  a  quadratic  function: 


m(ta,bi) 


-12 

ncm 

-  ,  where  ncm  is  the  number  of  constant  movements 

X  and  X  the  number  of  measurements. 


For  the  combination  of  other  aircraft  and  birds  we  take: 


m(nta,bi)  =  1 


ncm 


2 


The  other  belief  functions  are  given  in  ref.  28.  For  this  problem,  it 
turned  out  to  be  not  too  hard  to  define  the  functions.  What  is  a  problem, 
however,  is  that  Dempster's  rule  can  provide  counterintuitive  results  if 
the  belief  functions  are  not  defined  correctly. 

Unfortunately,  Shafer's  first  formulation  of  the  requirements  for  the  use 
of  this  rule  was  rather  vague  and  despite  several  atteiqpts  to  clarify  the 
meaning  of  the  requirements,  the  existing  formulations  are  still  not  ccsn- 
pletely  clear.  Recently,  Voorbraak  has  concluded  that  the  applicability  of 
the  Dempster-Shafer  theory  is  rather  limited,  since  bodies  of  evidence  have 


I 
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to  satisfy  very  strong  constraints  in  order  to  be  called  Dempster-Shafer- 
independent  (Ref.  29). 

7.  CONCLUSIONS  AND  FURTHER  WORK 


The  idea  of  not  committing  evidence  to  any  specific  event  or  set  of  events 
until  evidence  is  gained,  is  a  very  appealing  one  from  an  intuitive  point 
of  view.  The  Dempster-Shafer  theory  uses  the  concept  of  basic  probability 
functions  and  belief  functions  to  represent  this  idea. 

In  practice,  working  with  the  Dempster-Shafer  theory  is  not  easy,  and  it  is 
not  completely  clear  when  Dempster's  rule  of  combination  is  applicable. 

Application  of  the  theory  to  the  multi-radar  tracking  problem  has  brought 
greater  understanding  of  the  difficulties  of  using  the  theory. 

One  point  that  has  currently  received  more  attention  in  the  research  com¬ 
munity  is  the  relation  between  the  Dempster-Shafer  theory  and  other 
theories.  Especially  the  relation  between  the  Dempster-Shafer  theory  and 
the  Bayesian  subjective  probability  theory  and  between  the  Dempster-Shafer 
theory  and  possibilistic  reasoning  deserves  further  attention. 

Further  investigations  are  to  be  directed  towards  comparison  of  several 
methods  for  reasoning  with  uncertain  and  incomplete  information.  First  of 
all,  comparison  of  Bayesian  methods  and  the  Dempster-Shafer  theory  is 
needed.  The  multi-sensor  fusion  environment  applied  to  multi-radar  tracking 
has  proven  to  be  a  good  environment  to  perform  this  kind  of  work. 

Other  methods  for  reasoning  with  imperfect  information  are  needed  for  mul¬ 
ti-radar  tracking  purposed,  too.  Non-monotonic  reasoning  methods  deserve 
investigation  in  this  context. 
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1 4.  Abstract 
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